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) ----------------------------------- "IP over 802.16 Problem Statement and Goals", Junghoon Jee, Syam Madanapalli, Jeff Mandin, 20-Dec-07, This document specifies problems in running the IETF IP protocols over IEEE 802.16 networks by identifying specific gaps in the 802.16 MAC for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. Common terminology used for the base guideline while defining the solution framework is also presented. "Transmission of IP over Ethernet over IEEE 802.16 Networks", HongSeok Jeon, 11-Mar-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 subscriberstations. 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, 25-Feb-08, IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service specific convergence sublayers (Asynchronous Transfer Mode Convergence Sublayer (ATM CS) and Packet Convergence Sublayer (Packet CS) are the two main service specific convergence sublayers) for transmitting upper layer protocols. The packet CS 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 IP Convergence Sublayer of the IEEE 802.16. IPv6 Maintenance (6man) ----------------------- "Solution approaches for address-selection problems", Arifumi Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, Ken-ichi Kanayama, 30-Jan-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. "IPv6 Node Requirements RFC 4294-bis", John Loughney, 24-Feb-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, 8-Feb-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. ADSL MIB (adslmib) ------------------ "Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)", Moti Morgenstern, Scott Baillie, Umberto Bonollo, 29-Jan-08, This document defines a Management Information Base (MIB) module for use with network management protocols in the IfQueueBlockernet 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, 18-Nov-07, 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. "xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB", Edward Beili, Narendranath Nair, 19-Nov-07, 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 G.Bond MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), defined in ITU-T recommendation G.998.3. "Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB", Edward Beili, Moti Morgenstern, 19-Nov-07, 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 G.Bond MIB module with a set of objects for managing Ethernet-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.2. 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, 22-Feb-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, 9-Apr-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, 20-Nov-07, 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 [8]. The resulting protocol with the proposed extensions to GSMPv3 [4] 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 [8]. It is intended to be augmented by additional protocol specification for future use cases considered in scope by the ANCP charter. ANCP framework document [8] 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 Cnodder, Moti Morgenstern, 8-Nov-07, 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. "Address Autoconfiguration for MANET: Terminology and Problem Statement", Emmanuel Baccelli, Kenichi Mase, Simone Ruffino, Shubhranshu Singh, 26-Feb-08, This document states the problems pertaining to automatic IPv6 address configuration and prefix allocation in MANETs. 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 JPEG 2000 Video Streams", Satoshi Futemma, 12-Sep-07, This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, otherwise better known as: JPEG 2000. JPEG 2000 features are considered in the design of this payload format. JPEG 2000 is a truly scalable compression technology allowing applications to encode once and decode many different ways. JPEG 2000 video stream is formed by extending from a single image to a series of JPEG 2000 images. "RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family", Jun Matsumoto, Mitsuyuki Hatanaka, 8-Apr-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. "Definition of Events For Channel-Oriented Telephony Signalling", Tom Taylor, Henning Schulzrinne, 7-Jun-07, This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes and adds to the original assignment of event codes for this purpose in RFC 2833 section 3.14. As documented in Appendix A of RFC 4733, certain of the RFC 2833 events have been deprecated, because their specification was ambiguous, erroneous or redundant. In fact, the degree of change from RFC 2833 section 3.14 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. The positive benefits of the present document are an expanded coverage of signalling systems and a more carefully specified and documented coverage of signalling systems covered by RFC 2833. "Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery", Andrew Leung, 12-Sep-07, This memo describes extended uses for payload header in RFC document: "RTP Payload Format for JPEG 2000 Video Streams." For better support of JPEG 2000 features such as scalability and includes a main header recovery method. This memo must be accompanied with a complete implementation of "RTP Payload Format for JPEG 2000 Video Streams." That document is a complete description of the payload header and signaling, this document only describes additional processing for the payload header. There is an additional media type and SDP marker signaling for implementations of this document. "A general mechanism for RTP Header Extensions", David Singer, HariKishan Desineni, 11-Mar-08, This document provides a general mechanism to use the header- extension feature of RTP (the Real Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. "Associating Time-codes with RTP streams", David Singer, 11-Mar-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, 7-Nov-07, 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. "RTP Payload Format for Vorbis Encoded Audio", Luca Barbato, 19-Feb-08, This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and details the delivery mechanisms for the decoder probability model, referred to as a codebook and other setup information. Also included within this memo are media type registrations, and the details necessary for the use of Vorbis with the Session Description Protocol (SDP). "How to Write an RTP Payload Format", Magnus Westerlund, 25-Feb-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. "RTCP XR - Video Metrics Report Blocks", Alan Clark, Amy Pendleton, 19-Nov-07, This document defines extensions to the RTCP XR extended report packet type blocks to support the monitoring of video over IP for IPTV and videoconferencing endpoint reporting. "RTP Payload Format for SVC Video", Stephan Wenger, Ye-Kui Wang, Thomas Schierl, 25-Feb-08, This memo describes an RTP payload format for scalable video coding (SVC) defined in_Annex G of the ITU-T Recommendation H.264 video codec 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, produced by the video encoder, in each RTP packet payload. The payload format has wide applicability, such as low bit-rate conversational, Internet video streaming, or high bit-rate entertainment quality video. "RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, 14-Feb-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. "RTCP HR - High Resolution VoIP Metrics Report Blocks", Alan Clark, Geoff Hunt, Amy Pendleton, Rajesh Kumar, Kevin Connor, 25-Feb-08, This document defines extensions to the RTCP XR extended report packet type blocks to support Voice over IP (VoIP) monitoring for services that require higher resolution or more detailed metrics than those supported by RFC3611. "RTP Payload Format for DV (IEC 61834) Video", Katsushi Kobayashi, Kazuhiro Mishima, Stephen Casner, Carsten Bormann, 24-Mar-08, This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document Obsoletes RFC 3189. "RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec", Yusuke Hiwasaki, Hitoshi Ohmuro, 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, 8-Apr-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. "Parameters for Static Macroblocks and Aspect Ratio in the RTP Payload Format for H.264 Video", Tom Kristensen, Roni Even, 30-Jan-08, This document updates RFC 3984. It defines new optional parameters addressing recent extensions currently supported in H.323 systems: The signalling of the maximum rate of static macroblocks a decoder is able to process. The signalling of the sample aspect ratio supported by the sender or the receiver. "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", David McGrew, Eric Rescorla, 25-Feb-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. "RTCP XR - Audio Metrics Report Block", Alan Clark, Amy Pendleton, 19-Nov-07, This document defines extensions to the RTCP XR extended report packet type blocks to support the performance monitoring of audio streams transmitted using RTP. "Forward-shifted RTP Redundancy Payload Support", Qiaobing Xie, Joe Schumacher, 17-Mar-08, This document defines a simple enhancement to RFC 2198 to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data is 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, 19-Feb-08, This document describes the use of SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for confidentiality to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). "Support for non-compound RTCP, opportunities and consequences", Ingemar Johansson, 25-Feb-08, This memo discusses benefits and issues that arise when allowing RTCP packets to be transmitted as non-compound packets, i.e not follow the rules of RFC 3550. Based on that analysis this memo proposes changes to the rules to allow feedback messages to be sent as non-compound RTCP packets when using the RTP AVPF profile (RFC 4585) under certain conditions. "RTP Payload Format for H.264 RCDO Video", Tom Kristensen, 27-Dec-07, 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, 8-Feb-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, 9-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. "RTP Payload Format for SPIRIT IP-MR Speech Codec Software", Andrey Setsko, 4-Apr-08, This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload, introduced redundancy for robustness against packet loss, and payload format extension for future versions compatibility. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Session Traversal Utilities for (NAT) (STUN)", Jonathan Rosenberg, Rohan Mahy, Philip Matthews, Dan Wing, 23-Feb-08, Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. "NAT Behavioral Requirements for TCP", Saikat Guha, 30-Apr-07, This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Jonathan Rosenberg, Rohan Mahy, Philip Matthews, 25-Feb-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) located behind other NATs. 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. The TURN protocol can be used in isolation, but is more properly used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal. "Traversal Using Relays around NAT (TURN) Extension for IPv4/IPv6 Transition", Gonzalo Camarillo, Oscar Novo, 31-Jan-08, This document defines the REQUESTED-ADDRESS-TYPE attribute for the Traversal Using Relays around NAT (TURN), which allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). 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, 7-Feb-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, 25-Feb-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, 13-Nov-07, 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 and manage TCP connection with the client's peers. TURN and this extension both purposefully restricts 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, 10-Mar-08, The Session Traversal Utilities for NAT (STUN) protocol defines two STUN attributes -- FINGERPRINT and MESSAGE-INTEGRITY -- that may be included in STUN messages. This document provides test vectors for those two attributes. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "Bidirectional Forwarding Detection Management Information Base", Thomas Nadeau, Nobo Akiya, 25-Feb-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]. "BFD For MPLS LSPs", Rahul Aggarwal, 7-Nov-07, One desirable application of Bi-directional Forwarding Detection (BFD) is to detect a MPLS LSP data plane failure. LSP-Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However the control plane processing required for BFD control packets is relatively smaller than the processing required for LSP-Ping messages. A combination of LSP-Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP-Ping for this application. It also describes procedures for using BFD in this environment. "Bidirectional Forwarding Detection", Dave Katz, David Ward, 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. "BFD for Multipoint Networks", Dave Katz, David Ward, 16-Jan-08, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- "Basic Level of Interoperability for Session Initiation Protocol (SIP) Services (BLISS) Problem Statement", Jonathan Rosenberg, 24-Feb-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, 21-Feb-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, 26-Feb-08, This document analyzes the interoperability problems surrounding the call-completion feature that allows a callee to put a caller's request into a queue by which the caller can be notified to call back the callee at later time. This document analyzes how different solutions inter-operate and tries to make recommendation on how to best meet this requirement. Benchmarking Methodology (bmwg) ------------------------------- "Terminology for Benchmarking IPsec Devices", Michele Bustos, 25-Feb-08, This purpose of this document is to define terminology specific to measuring the performance of IPsec devices. It builds upon the tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF Benchmarking Methodology Working Group (BMWG) documents used for benchmarking routers and switches. This document seeks to extend these efforts specific to the IPsec paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. "Benchmarking Methodology for Link-State IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, Intellectual Property, 25-Feb-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, 25-Feb-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, 25-Feb-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 "Terminology for Accelerated Stress Benchmarking", Scott Poretsky, Shankar Rao, Intellectual Property, 25-Feb-08, This document provides the Terminology for performing Accelerated Stress Benchmarking of networking devices. The three phases of the Stress Test: Startup, Instability and Recovery are defined along with the benchmarks and configuration terms associated with the each phase. Also defined are the Benchmark Planes fundamental to stress testing configuration, setup and measurement. The "Methodology Guidelines for Accelerated Stress Benchmarking", Scott Poretsky, Shankar Rao, Intellectual Property, 25-Feb-08, Routers in an operational network are configured with multiple protocols and security policies while simultaneously forwarding traffic and being managed. To accurately benchmark a router for deployment it is necessary to test the router in a lab environment under accelerated conditions, which is known as Stress Testing. This document provides the Methodology Guidelines for performing Accelerated Stress Benchmarking of networking devices. The methodology is to be used with the companion terminology document [4]. These guidelines can be used as the basis for additional methodology documents that benchmark stress conditions for specific network technologies. for Accelerated Stress Benchmarking "Methodology for Benchmarking IPsec Devices", Merike Kaeo, Tim Van Herck, 25-Feb-08, The purpose of this draft is to describe methodology specific to the benchmarking of IPsec IP forwarding devices. It builds upon the tenets set forth in [RFC2544], [RFC2432] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the IPsec paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. "Benchmarking Terminology for Protection Performance", Scott Poretsky, 25-Feb-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, so avoid 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", Jay Karthik, Shankar Rao, 19-Feb-08, This draft describes the methodology for benchmarking MPLS Protection mechanisms for link and node protection as defined in [MPLS-FRR-EXT]. The benchmarking and terminology [TERM-ID] are to be used for benchmarking MPLS based protection mechanisms [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 riding on MPLS based primary tunnel. The terms used in the procedures included in this document are defined in [TERM-ID]. "IPv6 Benchmarking Methodology for Network Interconnect Devices", Chip Popoviciu, 7-Feb-08, The Benchmarking Methodologies defined in RFC2544 [9] are IP version independent. However, RFC 2544 does not address some of the specificities of IPv6. This document provides additional benchmarking guidelines, which in conjunction with RFC2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices. IPv6 transition mechanisms are outside the scope of this document. Better-Than-Nothing Security (btns) ----------------------------------- "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Joseph Touch, David Black, Yu-Shun Wang, 3-Oct-07, The Internet network security protocol suite, IPsec, consisting of IKE, ESP, and AH, generally requires authentication of network layer entities to bootstrap security. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates and associated asymmetric keys, or the use of Kerberos. The need to deploy authentication information and its associated identities to network layer entities can be a significant obstacle to use of network security. This document explains the rationale for extending the Internet network security suite to enable use of IPsec security mechanisms without authentication. These extensions are intended to protect communication in a "better than nothing" (BTNS) fashion. The extensions may be used on their own (Stand Alone BTNS, or SAB), or may be useful in providing network layer security that can be authenticated by higher layers in the protocol stack, called Channel Bound BTNS (CBB). This document also explains situations in which use of SAB and CBB extensions are appropriate. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec", Nicolas Williams, Michael Richardson, 4-Jan-08, This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better Than Nothing Security). "IPsec Channels: Connection Latching", Nicolas Williams, 25-Feb-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. This 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. A model of of connection latching is given. "IPsec Application Programming Interfaces", Michael Richardson, Nicolas Williams, Miika Komu, Sasu Tarkoma, 18-Feb-08, IPsec based security is usually transparent for applications and and they have no standard APIs for gathering information about protected network connections and for detecting the underlying security mechanisms. This document specifies an API that increases the visibility of IPsec to applications. The API allows applications to allow BTNS extensions, control the channel bindigs, and control also other security properties related to IPsec. "An abstract interface between applications and IPsec", Michael Richardson, 19-Feb-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 Transport-Independent Interoperability Protocol (iTIP)", Cyrus Daboo, 24-Feb-08, This document specifies a protocol using the iCalendar object specification to provide scheduling interoperability between different calendar 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 calendar systems. These scheduling methods permit two or more calendar systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel. Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- "CAPWAP Protocol Specification", Pat Calhoun, 17-Mar-08, This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF CAPWAP working group protocol requirements. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol. The CAPWAP protocol binding which defines extensions for use with the IEEE 802.11 wireless LAN protocol is available in [I-D.ietf-capwap-protocol-binding-ieee80211]. Extensions are expected to be defined to enable use of the CAPWAP protocol with additional wireless technologies. "CAPWAP Protocol Binding for IEEE 802.11", Pat Calhoun, 22-Feb-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. The CAPWAP Protocol Specification is defined separately [3]. "CAPWAP Threat Analysis for IEEE 802.11 Deployments", Scott Kelly, Charles Clancy, 23-Oct-07, 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 CAPWAP protocol is being developed in response. 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 CAPWAP implementations and deployments. "CAPWAP Access Controller DHCP Option", Pat Calhoun, 14-Mar-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. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", Kohei Shiomoto, Dimitri Papadimitriou, Jean-Louis Roux, Martin Vigoureux, Deborah Brungard, Eiji Oki, Ichiro Inoue, Emmanuel Dotaro, 8-Feb-08, Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies. In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a Multi-Region Network (MRN). When referring in general to a layered network, which may consist of either a single or multiple regions, this document uses the term, Multi-Layer Network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. "Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)", Jean-Louis Le Roux, Dimitri Papadimitriou, Deborah Brungard, Eiji Oki, Kohei Shiomoto, Martin Vigoureux, 17-Dec-07, This document provides an evaluation of Generalized Multi-Protocol Label Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLN) and Multi-Region Networks (MRN). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions. "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", Kohei Shiomoto, 22-Feb-08, This document discusses topics related to hierarchical and stitched Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs). It describes extensions to allow an egress to identify that a bi-directional LSP will be used as a dynamically signaled Forwarding Adjacency LSP (FA-LSP) or as a Routing Adjacency (RA). In addition, the document also discusses the issue of how to indicate that an LSP should be advertised as a traffic engineering (TE) link into a different instance of the IGP, and how to identify the instance that should be used. "Ethernet Traffic Parameters", Dimitri Papadimitriou, 20-Nov-07, This document described 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", Intellectual Property, 24-Feb-08, The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document provides the extensions of the OSPFv2 Link State Routing Protocol to meet the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. D.Papadimitriou et al. - Expires April 2008 [page 1] draft-ietf-ccamp-gmpls-ason-routing-ospf-05.txt Feb. 2008 "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", Zafar Ali, 12-Feb-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. "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", Greg Bernstein, 7-Feb-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 GMPLS", Thomas Nadeau, 25-Feb-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) as well as Generalized MPLS (GMPLS) for use with network management protocols. "Requirements for the Conversion Between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", Diego Caviglia, Dan Li, 18-Feb-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. "Analysis of Inter-domain Label Switched Path (LSP) Recovery", Tomonori Takeda, 24-Mar-08, This document analyzes various schemes to realize Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path (LSP) recovery in multi-domain networks based on the existing framework for multi-domain LSPs. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. It presents various diverse LSP setup schemes based on existing functional elements. "OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering", Mach Chen, Renhai Zhang, 9-Apr-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 TE information from outside the AS is proposed or defined in this document. "Description of the RSVP-TE Graceful Restart Procedures", Dan Li, 16-Nov-07, 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. "OAM Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Networks", Thomas Nadeau, 31-Oct-07, This document describes requirements for operations and management (OAM) for Generalized Multi-Protocol Label Switching (GMPLS) networks, as well as for applications of GMPLS. "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, 25-Feb-08, There are requirements for the support of networks ccomprising 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. "ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering", Mach Chen, Renhai Zhang, 9-Apr-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 TE information from outside the AS is proposed or defined in this document. "GMPLS Ethernet Label Switching Architecture and Framework", Don Fedyk, Lou Berger, Loa Andersson, 25-Feb-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, 15-Mar-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 LSPs", Lou Berger, Attila Takacs, Diego Caviglia, Don Fedyk, Julien Meuric, 12-Mar-08, This document defines a method for the support of GMPLS Asymmetric Bandwidth Bidirectional LSPs. The presented approach is applicable to any switching technology and builds on the original RSVP model for the transport of traffic related parameters. "Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in Generalized MPLS Networks", Weiqiang Sun, Guoying Zhang, Jianhua Gao, Guowu Xie, Rajiv Papneja, Bin Gu, Xueqing Wei, 26-Mar-08, Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for the future data transmission network. The GMPLS has been developed to control and cooperate 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 dynamically provisioned connections is increasing because optical networks are being deployed in metro area. 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 dynamical LSP setup/release performance. These metrics can depict the features of the GMPLS network 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, 27-Mar-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 Li Expires September 2008 [page 1] draft-ietf-ccamp-confirm-data-channel-status-00.txt March 2008 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, 27-Mar-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. To preserve confidentiality of topology with each AS, the PCE supports a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS). This document describes the addition of this information to Resource Reservation Protocol (RSVP) signaling by inclusion in the Explicit Route Object (ERO) and Record Route Object (RRO). "RSVP-TE Signaling Extension For The Conversion Between Permanent Connections And Soft Permanent Connections In A GMPLS enabled Transport Network", Diego Caviglia, Dan Li, Intellectual Property, 28-Mar-08, In a transport network scenario, where Data Plane connections controlled either by GMPLS (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 valuable option. This applies especially when a GMPLS based Control Plane is first introduced into an existing network and there may be the need, from a Carrier point of view, to pass under GMPLS control existing connections already set up over Data Plane. In other terms, such operation could 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 provides a minor extension to RSVP-TE signaling protocol, within GMPLS architecture, to enable such connection ownership transfer and describes the proposed procedures. Datagram Congestion Control Protocol (dccp) ------------------------------------------- "Faster Restart for TCP Friendly Rate Control (TFRC)", Eddie Kohler, Sally Floyd, Arjuna Sathiaseelan, 19-Nov-07, 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. "TCP Friendly Rate Control (TFRC): Protocol Specification", University London, Sally Floyd, Jitendra Padhye, Joerg Widmer, Intellectual Property, 25-Feb-08, This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance. "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", Thomas Phelan, 6-Feb-08, This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for datagram protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. "The DCCP Service Code", Gorry Fairhurst, 18-Feb-08, This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of Service Codes 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). The document updates the specification provided in RFC 4340. "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", Sally Floyd, Eddie Kohler, 9-Feb-08, This document specifies an experimental profile for Congestion Control Identifier 4, the Small-Packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP [RFC4828], a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for experimental use for senders that send small packets and would like a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. "DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal", Gorry Fairhurst, Gerrit Renker, 18-Feb-08, This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update assists DCCP applications which need to communicate through one or more middleboxes (e.g. Network Address Translators or firewalls), where establishing necessary middlebox state requires peering endpoints to initiate communication in a near-simultaneous manner. Dynamic Host Configuration (dhc) -------------------------------- "Virtual Subnet Selection Sub-Option for the Relay Agent Information Option for DHCPv4", Kim Kinnear, Richard Johnson, Mark Stapp, Jay Kumarasamy, 18-Dec-07, In some environments, a relay agent resides in a network element which also has access to one or more virtual private networks (VPNs). If a DHCP server wishes to offer service to DHCP clients on those different VPNs the DHCP server needs to know information about the VPN on which each client resides. The Virtual Subnet Selection sub- option of the relay-agent-information option is used by the relay agent to tell the DHCP server important information about the VPN (called the Virtual Subnet Selection information, or VSS) for every DHCP request it passes on to the DHCP server, and is also used to properly forward any DHCP reply that the DHCP server sends back to the relay agent. "Virtual Subnet Selection Options for DHCPv4 and DHCPv6", Kim Kinnear, Richard Johnson, Mark Stapp, Jay Kumarasamy, 22-Feb-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. "Subnet Allocation Option", Richard Johnson, 16-Nov-07, 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 RFC-3942[4], 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. "DHCP options for PANA Authentication Agents", Lionel Morand, 18-Dec-06, This document defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more of PANA Authentication Agents (PAA). This is one of the methods that a PANA Client (PaC) can use to locate PANA Authentication Agents (PAA). "Rebind Capability in DHCPv6 Reconfigure Messages", D Evans, Ralph Droms, 4-Dec-07, This document updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which allows DHCPv6 servers to instruct clients to perform a Rebind operation as well as a Renew operation. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. "Container Option for Server Configuration", Ralph Droms, 24-Jan-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, 28-Jan-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, 11-Feb-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 specifies extensions to the Leasequery protocol that add new query types and allow for bulk transfer of DHCPv6 binding data. Diameter Maintenance and Extensions (dime) ------------------------------------------ "The Diameter API", Pat Calhoun, David Frascone, 12-Feb-08, The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes a standardized API for the Diameter protocol. The API is defined for the C language. The intent of the API is to foster source code portability across multiple programming platforms. "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", Jouni Korhonen, Hannes Tschofenig, Julien Bournelle, Gerardo Giaretta, Madjid Nakhjiri, 25-Feb-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, 14-Feb-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 the 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, Glenn Zorn, 22-Jan-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, 25-Feb-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, 23-Jan-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 which further explains and/or clarify 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, 25-Feb-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", Hannes Tschofenig, Mayutan Arumaithurai, Mark Jones, 25-Feb-08, This document extends the QoSFilterRule 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, 25-Feb-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. An organization may use one or more domain names to accomplish this. DKIM defines a domain-level digital signature authentication framework for email, using public-key cryptography and key server technology [RFC4871]. This permits verification of a message source, an intermediary, or one of their agents, as well as the integrity of its 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. Such protection of email identity can assist in the global control of "spam" and "phishing". "DKIM Author Signing Practices (ASP)", Eric Allman, Jim Fenton, Mark Delany, John Levine, 23-Feb-08, DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transport Agents (MTAs) or Mail User Agents (MUAs). The primary DKIM protocol is described in [RFC4871]. This document describes the records that authors' domains can use to advertise their practices for signing their outgoing mail, and how other hosts can access those records. "DomainKeys Identified Mail (DKIM) Development, Deployment and Operations", Tony Hansen, Phillip Hallam-Baker, Dave Crocker, 25-Feb-08, DomainKeys Identified Mail (DKIM) associates a "responsible" identity with a message and provides a means of verifying that the association is legitimate. [RFC4871] DKIM defines a domain-level authentication framework for email using public-key cryptography and key server technology. This permits verifying the source or intermediary for a message, as well as the contents of messages. The ultimate goal of this framework is to permit a signing domain to assert responsibility for sending a message, thus proving and protecting the identity associated with the message and the integrity of the messages itself, while retaining the functionality of Internet email as it is known today. Such protection of email identity may assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational and migration considerations for DKIM. Detecting Network Attachment (dna) ---------------------------------- "Detecting Network Attachment in IPv6 Networks (DNAv6)", Sathya Narayanan, James Kempf, Erik Nordmark, Brett Pentland, JinHyeock Choi, Greg Daley, Nicolas Montavont, 24-Feb-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 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. "Simple procedures for Detecting Network Attachment in IPv6", Suresh Krishnan, Greg Daley, 4-Apr-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)", Andreas Gustafsson, 5-Feb-08, The Domain Name System standard facilities for maintaining coherent servers for a zone consist of three elements. The Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The Incremental Zone Transfer (IXFR) is defined in RFC 1995. A mechanism for prompt notification of zone changes (NOTIFY) is defined in RFC 1996. The base definition of these facilities, that of the AXFR, has proven insufficient in detail, resulting in no implementation complying with it. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of the AXFR, new in the sense that is it recording an accurate definition of an interoperable AXFR mechanism. "Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, Rob Austein, 18-Nov-07, 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, 9-Aug-07, 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, 16-Feb-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, 25-Mar-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 an update to 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 van Mook, 24-Mar-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 answers 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 answers. This document updates RFC 1034. "Revised extension mechanisms for DNS (EDNS0)", Paul Vixie, 17-Mar-08, The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow.1 - Introduction "The Modern DNS Implementation Guide", George Michaelson, 20-Jan-08, A structured catalogue of relevant DNS RFCs is presented with references to the specific normative sections which should be followed in a modern DNS implementation. This document is to be used as guide for DNS implementors, for testing and compliance of DNS software, and to help guide DNS standards' advancement. Domain Name System Operations (dnsop) ------------------------------------- "DNS Referral Response Size Issues", Paul Vixie, Akira Kato, 23-Feb-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. "Preventing Use of Recursive Nameservers in Reflector Attacks", Joao Luis Damas, Frederico Neves, 3-Dec-07, This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. Recommended configuration as measures to mitigate the attack are given. "Locally-served DNS Zones", Mark Andrews, 3-Dec-07, 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. "Considerations for the use of DNS Reverse Mapping", Daniel Senie, Andrew Sullivan, 13-Mar-08, Mapping of addresses to names is a feature of DNS. Many sites implement it, many others do not. Some applications attempt to use it as a part of a security strategy. This document outlines what should be taken into account when deciding whether to implement reverse mappings of addresses to names, suggests that site administrators implement reverse mappings if there are no strong considerations against such mappings, and provides considerations to be taken into account when using reverse mappings. "I'm Being Attacked by PRISONER.IANA.ORG!", Joe Abley, William Maton, 18-Nov-07, Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Hosts should never normally send reverse DNS queries for those addresses on the public Internet. However, such queries are frequently observed. Authority servers are deployed to provide authoritative answers to such queries as part of a loosely- coordinated effort known as the AS112 project. Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked. This document provides background information and technical advice to those firewall operators. "AS112 Nameserver Operations", Joe Abley, William Maton, 16-Nov-07, Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Devices in such environments may occasionally originate reverse DNS queries corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that they are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the root and IN-ADDR.ARPA authority servers. This document describes the steps required to install a new AS112 node, and offers advice relating to such a node's operation. "DNSSEC Trust Anchor Configuration and Maintenance", Matt Larson, Olafur Gudmundsson, 11-Feb-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. Email Address Internationalization (eai) ---------------------------------------- "SMTP extension for internationalized email address", Jiankang Yao, Wei MAO, 4-Apr-08, This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. "UTF-8 Mail: Scenarios", Harald Alvestrand, 25-Jan-08, This document describes some scenarios in which one can imagine internationalized email addresses deployed, and tries to draw some conclusions about what's acceptable and what's not for users in those scenarios. One possible set of extensions that can work in these scenarios is those described in the UTF8SMTP extension documents. "Downgrading mechanism for Email Address Internationalization", Kazunori Fujiwara, Yoshiro Yoneya, 13-Mar-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 bouncing 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, 18-Nov-07, 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. "Internationalized Email Headers", Jeff Yeh, 8-Feb-08, Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. "Mailing Lists and Internationalized Email Addresses", Randall Gellens, Edmon Chung, 22-Feb-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. Gellens & Chung [page 1] Expires August 2008 Internet Draft Mailing Lists and i18mail Addresses February 2008 "POP3 Support for UTF-8", Chris Newman, Randall Gellens, 24-Feb-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. "Internationalized Delivery Status and Disposition Notifications", Chris Newman, Alexey Melnikov, 21-Jan-08, Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing draft standard is presently limited to US-ASCII text in the machine readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document experimentally extends RFC 3461, RFC 3464 and RFC 3798. "An update to the mailto URI scheme for Email Address Internationalization", Martin Duerst, 18-Feb-08, This document updates the definition of the mailto: URI Scheme for use with internationalized email addresses. Extensible Authentication Protocol (eap) ---------------------------------------- "Extensible Authentication Protocol (EAP) Key Management Framework", Bernard Aboba, Daniel Simon, Pasi Eronen, 12-Nov-07, The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "LoST: A Location-to-Service Translation Protocol", Ted Hardie, Andrew Newton, Henning Schulzrinne, Hannes Tschofenig, 28-Mar-08, This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. "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, 25-Feb-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, 25-Feb-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. "A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure", Henning Schulzrinne, 11-Jul-07, The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desireable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). Electronic Data Interchange-Internet Integration (ediint) --------------------------------------------------------- "Compressed Data within an Internet EDI Message", Terry Harding, 25-Mar-08, Harding [page 1] Compressed Data within an Internet EDI Message September 2008 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. EAP Method Update (emu) ----------------------- "EAP Generalized Pre-Shared Key (EAP-GPSK)", Charles Clancy, Hannes Tschofenig, 4-Dec-07, This Internet Draft defines an Extensible Authentication Protocol method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. Telephone Number Mapping (enum) ------------------------------- "ENUM Implementation Issues and Experiences", Lawrence Conroy, Kazunori Fujiwara, 14-Feb-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 DDDS 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. "IANA Registration of Enumservices: Guide, Template and IANA Considerations", Bernie Hoeneisen, Alexander Mayrhofer, Jason Livingood, 10-Mar-08, This document specifies a revision of the IANA registry for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservices and its Registration Documents. "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' URI type 'pstn'", Richard Shockey, 5-Oct-07, This document registers the Enumservice 'pstn' and subtype 'cnam' using the URI scheme 'pstndata:' as per the IANA registration process defined in the ENUM specification, RFC 3761[1] and registers a new URI type 'pstndata:' according to the URI registration procedure in RFC 4395 [15]. 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". "ENUM-based Softswitch Requirement", JoonHyung Lim, Weon Kim, ChanKi Park, Lawrence Conroy, 24-Oct-07, This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean VoIP carriers, gained during the ENUM pre- commercial trial hosted by National Internet Development Agency of Korea (NIDA) in 2006. These experiences show that an interim solution can maintain the stability of on-going commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. "Registration of Enumservices for experimental, private or trial use", Bernie Hoeneisen, 5-Nov-07, This document provides a guide to the creation of new IANA registrations of experimental, private or trial ENUM (E.164 Number Mapping) services. It is also to be used for updates of those experimental, private or trial Enumservice (X-Enumservice) registrations. "IANA Registration of Enumservices for Voice and Video Messaging", Jason Livingood, Donald Troshynski, 18-Dec-07, This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice and/or video communications to a messaging system. This vmsg Enumservice registers three Enumservice types; "voicemsg", "videomsg", and "unifmsg". FEC Framework (fecframe) ------------------------ "FECFRAME requirements", Mark Watson, 3-Dec-07, This document defines requirements for a "FEC Framework" to be defined by the IETF FECFRAME working group. The object of this group is primarily to develop specifications for using forward error correction (FEC) codes with applications in the Internet to provide protection against packet loss. "Forward Error Correction (FEC) Framework", Mark Watson, 16-Nov-07, 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, 9-Feb-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 the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Forwarding Element Model", Joel Halpern, Ellen Deleganes, Jamal Hadi Salim, 25-Feb-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 [4]. "ForCES Protocol Specification", Ligang Dong, Avri Doria, Ram Gopal, Robert HAAS, Jamal Hadi Salim, Hormuzd Khosravi, Weiming Wang, 11-Mar-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 messages, the specification also defines the framework, the mechanisms, and the Transport Mapping Layer (TML) requirements for ForCES protocol.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, 11-Mar-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, 11-Nov-07, 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, 29-Mar-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, 31-Jan-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, 19-Feb-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. "Binary to Decimal Conversion for Location Configuration Information", John Schnizlein, Marc Linsner, 18-Dec-07, This document describes the nature of the data expressed in the geographic LCI defined in RFC 3825, and includes examples of conversion from its binary format to decimal character strings. "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", Hannes Tschofenig, Henning Schulzrinne, 29-Mar-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, 9-Apr-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) as a transport for the protocol. "Requirements for a Location-by-Reference Mechanism", Roger Marshall, 25-Feb-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, 10-Dec-07, A method is described for the discovery of a Location Information Server. The method consists of attempting to use a Dynamic Host Configuration Protocol (DHCP) option, followed by a URI-enabled NAPTR (U-NAPTR). DHCP options are defined for both IPv4 and IPv6 DHCP. This document also 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, 18-Feb-08, This document creates a Dynamic Host Configuration Protocol (DHCP) Option for the Location Uniform Resource Identifier (URI) of an endpoint. For example, an endpoint can be a Session Initiation Protocol (SIP) User Agent (i.e., a phone). This Location-URI can be included in a UA's signaling messages to inform other nodes of that entity's geographic location, once the URI is dereferenced by a Location Recipient. Global Routing Operations (grow) -------------------------------- "MRT routing information export format", Larry Blunk, Manish Karir, Craig Labovitz, 25-Feb-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. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol", Robert Moskowitz, Pekka Nikander, Petri Jokela, Tom Henderson, 30-Oct-07, This memo specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie- Hellman key exchange, using public-key identifiers from a new Host Identity name space for mutual peer authentication. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the- middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper layer protocols, such as TCP and UDP. "End-Host Mobility and Multihoming with the Host Identity Protocol", Tom Henderson, 5-Mar-07, This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host-- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", Pekka Nikander, Julien Laganier, 13-Apr-07, This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVS). "Host Identity Protocol (HIP) Rendezvous Extension", Julien Laganier, Lars Eggert, 7-Jun-06, This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. "Using ESP transport format with HIP", Petri Jokela, 12-Jun-07, This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). "Host Identity Protocol (HIP) Registration Extension", Julien Laganier, 7-Jun-06, This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. "Basic HIP Extensions for Traversal of Network Address Translators and Firewalls", Miika Komu, Tom Henderson, Philip Matthews, Hannes Tschofenig, Ari Keraenen, Jan Melen, Marcelo Bagnulo, 25-Feb-08, The Host Identity Protocol (HIP) provides a new namespace that can be used for uniquely identifying hosts. Existing HIP experimental specifications do not specify protocol operations across Network Address Translators (NATs). This document specifies NAT traversal extensions for HIP. The HIP shim layer is located between the network and transport layer, the extensions can also provide a more general-purpose NAT traversal support for higher-layer networking applications. The extensions are based on the use of the The Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts. Using the specified extensions, two HIP-capable hosts are able to communicate with each other even when both nodes are behind NATs or firewalls. "Basic Socket Interface Extensions for Host Identity Protocol (HIP)", Miika Komu, Tom Henderson, 25-Feb-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. "Using the Host Identity Protocol with Legacy Applications", Tom Henderson, Pekka Nikander, Miika Komu, 19-Nov-07, This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP. Handover Keying (hokey) ----------------------- "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", Joseph Salowey, Lakshminath Dondeti, Vidya Narayanan, Madjid Nakhjiri, 24-Feb-08, An Extended Master Session Key (EMSK) is a cryptographic key generated from an Extensible Authentication Protocol (EAP) exchange reserved solely for the purpose of deriving master keys for one or more purposes identified as usage definitions. This memo specifies a mechanism for avoiding conflicts between root keys by deriving cryptographically separate keys from the EMSK. This document also describes a usage for domain specific root keys made available to and used within specific key management domains. "EAP Extensions for EAP Re-authentication Protocol (ERP)", Vidya Narayanan, Lakshminath Dondeti, 29-Mar-08, The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network that the peer is connecting to. "Derivation, delivery and management of EAP based keys for handover and re-authentication", Madjid Nakhjiri, Yoshihiro Ohba, 25-Feb-08, This document describes a framework and a mechanism for deliverying usage specific root keys (USRK and DSUSRK), derived as part of an EAP EMSK hierarchy, and delivered from a server to an intended third party key holder. The framework description includes different scenarios for key delivery, depending on the type of keys being delivered. It also includes, specification of derivation of keys required for security protection of key requests and delivery signaling. The mechanism description includes the definition for a three-party key distribution exchange (KDE) protocol. "EAP Pre-authentication Problem Statement", Yoshihiro Ohba, 22-Feb-08, EAP pre-authentication is defined as the utilization of EAP to pre- establish EAP keying material on an authenticator prior to arrival of the peer at the access network managed by that authenticator. This draft discusses EAP pre-authentication problems in details. 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, 25-Feb-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, 25-Feb-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, 25-Feb-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, 25-Feb-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, 25-Feb-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, 25-Feb-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, 25-Feb-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, 22-Feb-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. Internet Architecture Board (iab) --------------------------------- "Design Choices When Expanding DNS", Patrik Faltstrom, Rob Austein, Peter Koch, 18-Feb-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. Inter-Domain Routing (idr) -------------------------- "Outbound Route Filtering Capability for BGP-4", Enke Chen, Yakov Rekhter, 25-Sep-06, This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version", Jeffrey Haas, 11-Nov-07, 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. "Address Prefix Based Outbound Route Filter for BGP-4", Enke Chen, Srihari Sangli, 21-Jul-06, This document defines a new Outbound Router Filter type for BGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address prefix based route filtering. This ORF-type supports prefix length or range based matching, wild-card based address prefix matching, as well as the exact address prefix matching for address families. "Advertising an IPv4 NLRI with an IPv6 Next Hop", Francois Le Faucheur, Eric Rosen, 16-Oct-07, 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. "Dissemination of flow specification rules", Pedro Roque Marques, Nischal Sheth, Robert Raszuk, Barry Greene, Danny McPherson, 2-Apr-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. Internet Message Access Protocol Extension (imapext) ---------------------------------------------------- "INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS", Mark Crispin, Ken Murchison, 13-Mar-08, This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. "IMAP ANNOTATE Extension", Randall Gellens, Cyrus Daboo, 19-Oct-06, The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen or important, or a comment added. "IMAP4 LIST Command Extensions", Barry Leiba, Alexey Melnikov, 26-Sep-06, IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. "Internet Message Access Protocol Internationalization", Chris Newman, Arnt Gulbrandsen, Alexey Melnikov, 1-Feb-08, Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions which improve international support including comparator negotiation for search, sort and thread, language negotiation for international error text, and translations for namespace prefixes. Internet and Management Support for Storage (imss) -------------------------------------------------- "MIB for Fibre-Channel Security Protocols (FC-SP)", Claudio DeSanti, Fabio Maino, Keith McCloghrie, 18-Mar-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 information related to FC-SP, the Security Protocols defined for Fibre Channel. IP over Cable Data Network (ipcdn) ---------------------------------- "Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices", Sumanth Channabasappa, 18-Nov-07, 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 - March 2008 [page 1] PacketCable/IPCablecom Event management MTA MIB September 2007 IP over DVB (ipdvb) ------------------- "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Prashant Pillai, 4-Apr-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. "Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)", Gorry Fairhurst, Bernhard Collini-Nocker, 7-Jan-08, This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC4326. The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic Stream Encapsulation (GSE) defined to support the second generation framing structure defined by Digital Video Broadcasting (DVB) family of specifications. 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. "IPFIX Implementation Guidelines", Elisa Boschi, 18-Dec-07, The IP Flow Information eXport (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address template management, transport-specific issues, implementation of exporting and collecting processes and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.). "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, 11-Feb-08, This document presents a list of tests that implementers of IP Flow Information Export (IPFIX) compliant Exporting Processes and Collecting Processes should perform on their IPFIX Exporting Process and/or Collecting Process. This document has been created to help implementers test the functionality of their IPFIX Exporting Process and/or Collecting Process. The goal of these tests is to ensure that all important functions are covered by tests and thereby to gain a level of confidence in the Exporting Process and Collecting Process that allows 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, 22-Feb-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. "An IPFIX-Based File Format", Brian Trammell, Elisa Boschi, Lutz Mark, Tanja Zseby, Arno Wagner, 21-Feb-08, This document describes a file format for the storage of flow data based upon the IPFIX Message format. It proposes a set of requirements for flat-file, binary flow data file formats, then applies the IPFIX message format to these requirements to build a new file format. This IPFIX-based 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, 25-Feb-08, This document describes an extension to IPFIX to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream, to allow the export of extended type information for enterprise- specific Information Elements. This format is designed to facilitate interoperability and reusability among a wide variety of applications and tools. IP over Resilient Packet Rings (iporpr) --------------------------------------- "Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring) Networks", Marc Holness, Glenn Parsons, 21-Aug-06, This document specifies a basic standard method of encapsulating IPv4, IPv6, and MPLS datagrams into IEEE 802.17 Resilient packet ring (RPR) datagrams. IP Performance Metrics (ippm) ----------------------------- "A Two-way Active Measurement Protocol (TWAMP)", Jozef Babiarz, 18-Dec-07, The IP Performance Metrics (IPPM) working group's One-way Active Measurement Protocol [RFC4656] (OWAMP) provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. "IP Performance Metrics (IPPM) for spatial and multicast", Emile Stephan, Lei Liang, Al Morton, 15-Feb-08, The IETF IP Performance Metrics (IPPM) working group has standardized metrics 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, 25-Feb-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, 6-Feb-08, This memo describes a framework for composing and aggregating metrics (both in time and in space) defined by RFC 2330 and developed by the IPPM working group. The framework describes the generic composition and aggregation mechanisms. It provides a basis for additional documents that implement this framework for detailed, and practically useful, compositions and aggregations of metrics. "Information Model and XML Data Model for Traceroute Measurements", Saverio Niccolini, Sandra Tartarelli, Juergen Quittek, Martin Swany, 25-Feb-08, This document describes a standard way to store the configuration and the results of traceroute measurements. This document first of all describes the tool itself; afterwards, the common information model is defined dividing the information elements in two semantically separated groups (configuration elements and results ones). Moreover an additional element is defined to relate configuration elements and results ones by means of a common unique identifier. On the basis of the information model a data model based on XML is defined to store the results of traceroute measurements. "A One-Way Packet Duplication Metric for IPPM", Henk Uijterwaal, 11-Feb-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, the IPPM (IP Performance Metrics) group defined a metric for packet loss. This metric quantifies the case where a packet that is sent, never arrives at its destination. In this memo, a metric for the opposite 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", Benoit Claise, 17-Feb-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. Intellectual Property Rights (ipr) ---------------------------------- "Advice to the Trustees of the IETF Trust on Rights to be Granted in IETF Documents", Joel Halpern, 19-Mar-08, Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement and otherwise use IETF contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF contributions. "Rights Contributors provide to the IETF Trust", Scott Bradner, Jorge Contreras, 23-Mar-08, The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFC 3978 and 4748 and, with RFC 3979 and RFC xxx (rfc editor - replace with the RFC # of -outgoing), replaces Section 10 of RFC 2026. 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. IP Telephony (iptel) -------------------- "The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry", Cullen Jennings, Vijay Gurbani, 25-Mar-08, This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. IS-IS for IP Internets (isis) ----------------------------- "Routing IPv6 with IS-IS", Christian Hopps, 5-Oct-07, This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes 2 new TLVs, a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. "Point-to-point operation over LAN in link-state routing protocols", Naiming Shen, 20-Apr-06, The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. "IS-IS extensions for Traffic Engineering", Tony Li, Henk Smit, 7-Apr-08, This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. "Simplified Extension of LSP Space for IS-IS", Les Ginsberg, Stefano Previdi, Mike Shand, Danny McPherson, 5-Dec-07, This draft describes a simplified method for extending the LSP space beyond the 256 Link State PDU (LSP) limit defined in [ISO 10589]. This method is intended as a preferred replacement for the method defined in [RFC 3786]. "IS-IS Generic Cryptographic Authentication", Manav Bhatia, 7-Nov-07, This document proposes an extension to 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 3567. Although this document has been written specifically for using HMAC construct along with the 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. "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", Kireeti Kompella, Yakov Rekhter, 7-Apr-08, This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). "Dynamic Hostname Exchange Mechanism for IS-IS", Danny McPherson, Naiming Shen, 8-Apr-08, Currently, there does not exist a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. This document defines a new TLV which allows the IS-IS routers to flood their name-to-systemID mapping information across the IS-IS network. The intention of this document is to provide an update to [RFC 2763]. "IS-IS Transient Blackhole Avoidance", Danny McPherson, Naiming Shen, 20-Oct-07, This document describes a simple, interoperable mechanism that can be employed in IS-IS networks in order to decrease data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. The intention of this document is to provide an update to [RFC 3277]. "Advertising Generic Information in IS-IS", Les Ginsberg, Stefano Previdi, Mike Shand, 31-Oct-07, 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. "Restart Signaling for Intermediate System to Intermediate System (IS-IS)", Mike Shand, Les Ginsberg, 1-Nov-07, This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", Tony Li, Randall Atkinson, 17-Mar-08, This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. "Domain-wide Prefix Distribution with Two-Level IS-IS", Tony Li, Henk Smit, Tony Przygienda, 17-Mar-08, This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966. This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. "IS-IS Multi-Instance", Stefano Previdi, Les Ginsberg, Mike Shand, David Ward, Abhay Roy, 18-Feb-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. "IS-IS BFD Enabled TLV", Christian Hopps, Les Ginsberg, 23-Mar-08, This document describes a TLV for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection protocol (BFD). There exist certain scenarios in which IS-IS will not react appropriately to a BFD detected forwarding plane failure without use of either this TLV or some other method. "Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies", Dave Katz, Rajesh Saluja, 2-Apr-08, The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. Integrated Security Model for SNMP (isms) ----------------------------------------- "Secure Shell Transport Model for SNMP", David Harrington, Joseph Salowey, 25-Feb-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, 25-Feb-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 transport to include secure transport 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, 18-Nov-07, 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 use with network management protocols in TCP/IP based internets. In particular it defines objects 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, 24-Feb-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, 25-Feb-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. It is intended that this document or a successor version thereto will become the basis for subsequent progression of a symmetric key provisioning protocol specification on the standards track. "Portable Symmetric Key Container", Philip Hoyer, 26-Feb-08, This document specifies a symmetric key format for transport and provisioning of symmetric keys (One Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of strong authentication devices. The standard token format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a format that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. "Symmetric Key Package Content Type", Sean Turner, Russ Housley, 25-Feb-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) ----------------------------------------- "GSS-API Internationalization and Domain-Based Service Names and Name Type", Nicolas Williams, Alexey Melnikov, 25-Jan-08, This document describes domainname-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Internationalization of the GSS-API is also covered. Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names. "GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism", Nicolas Williams, 25-Jan-08, This document describes the mapping of GSS-API domainname-based service principal names onto Kerberos V principal names. "Extended Generic Security Service Mechanism Inquiry APIs", Nicolas Williams, 21-Mar-08, This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications. These interfaces include: mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that posses given attributes, and a function for displaying mechanism attributes. "Clarifications and Extensions to the GSS-API for the Use of Channel Bindings", Nicolas Williams, 13-Mar-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. "Namespace Considerations and Registries for GSS-API Extensions", Nicolas Williams, 25-Mar-08, This document describes the ways in which the GSS-API may be extended and directs the creation of an IANA registry for various GSS-API namespaces. Kerberos (krb-wg) ----------------- "Generating KDC Referrals to Locate Kerberos Realms", Kenneth Raeburn, Larry Zhu, 25-Feb-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. "A Generalized Framework for Kerberos Pre-Authentication", Larry Zhu, Sam hartman, 24-Feb-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. "ECC Support for PKINIT", Larry Zhu, Karthik Jaganathan, Kristin Lauter, 24-Oct-07, This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT - the Kerberos Version 5 extension that provides for the use of public key cryptography. "Anonymity Support for Kerberos", Larry Zhu, Paul Leach, 30-Jan-08, This document defines extensions to the Kerberos protocol for the Kerberos client to authenticate the Kerberos Key Distribution Center and the Kerberos server, without revealing the client's identity. It updates RFC 4120. These extensions can be used to secure communication between the anonymous client and the server. "Additional Kerberos Naming Constraints", Larry Zhu, 24-Oct-07, This document defines new naming constraints for well-known Kerberos principal name and well-known Kerberos realm names. "Kerberos Version 5 GSS-API Channel Binding Hash Agility", Shawn Emery, 10-Nov-07, Currently, the Kerberos Version 5 Generic Security Services Application Programming Interface (GSS-API) mechanism [RFC4121] does not have the ability to utilize better hash algorithms used to generate channel binding identities. The current mechanism for doing this is hard coded to use MD5 only. The purpose of this document is to outline changes required to update the protocol so that more secure algorithms can be used to create channel binding identities. The extensibility of this solution also provides an eventual replacement of identities based solely on hash algorithms. "Problem statement on the cross-realm operation of Kerberos", Shoichi Sakane, 18-Dec-07, 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, 14-Feb-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, 31-Oct-07, 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 Johasson, 6-Feb-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) ---------------------------------------- "BGP-based Auto-Discovery for Layer-1 VPNs", Hamid Ould-Brahim, 8-Feb-08, The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of PEs having ports attached to CE members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. "Layer 1 VPN Basic Mode", Don Fedyk, Yakov Rekhter, Richard Rabbat, Lou Berger, 21-Feb-08, This document describes the Basic Mode of Layer 1 VPNs (L1VPN BM). L1VPN Basic mode is a port-based VPN. In L1VPN Basic Mode (BM), the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port-topology. This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM. "OSPF Based Layer 1 VPN Auto-Discovery", Igor Bryskin, Lou Berger, 22-Feb-08, This document defines an Open Shortest Path First (OSPF) based Layer-1 Virtual Private Network (L1VPN) auto-discovery mechanism. This mechanism enables provider edge (PE) devices using OSPF to dynamically learn about existence of each other, and attributes of configured customer edge (CE) links and their associations with L1VPNs. This document builds on L1VPN framework and requirements, and provides a L1VPN basic mode auto-discovery mechanism.Contents "Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs) Basic Mode", Adrian Farrel, Hamid Ould-Brahim, Tomonori Takeda, 21-Feb-08, This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs). L1VPNs provide customer services and connectivity at layer 1 over layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode where the Basic Mode of operation does not feature any exchange of routing information between the layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN. T.Takeda, et al. Expires August 2008 [page 1] draft-ietf-l1vpn-applicability-basic-mode-04.txt February 2008 Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3)", Carlos Pignataro, 13-Jan-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, 20-Nov-07, This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for support of structure-agnostic and structure-aware TDM pseudowires. "RADIUS & L2TP Extended NAS-Port AVPs", Tom Mistretta, 17-Dec-07, This document defines additional Layer 2 Tunneling Protocol (L2TP) and Remote Authentication Dial In User Service (RADIUS) Attribute- Value Pairs (AVPs) to communicate Network Access Server (NAS) informational UTF-8 text and port usage information between L2TP peers during call establishment to facilitate authorization, accounting and logging. 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). "IP-Only LAN Service (IPLS)", Himanshu Shah, 22-Feb-08, A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems which are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination MAC addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in [IEEE 802.1D]. This draft specifies the protocol extensions and procedures for support of the IPLS service. "L2VPN OAM Requirements and Framework", Dinesh Mohan, Ali Sajassi, 21-Sep-07, This draft provides framework and requirements for Layer 2 Virtual Private Networks (L2VPN) Operation, Administration and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN) tunnels. The requirements are intended to identify OAM requirement for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if L2VPN services OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. "ARP Mediation for IP Interworking of Layer 2 VPN", Himanshu Shah, 22-Feb-08, The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. "Requirements for Multicast Support in Virtual Private LAN Services", Yuji Kamite, 12-Sep-07, 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, 17-Nov-07, 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 backbone 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", Ali Sajassi, 4-Oct-07, One of the main motivations behind VPLS is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer bridges. If only connectivity among customer IP routers/hosts was desired, then IPLS solution [IPLS] could have been used. The strength of the VPLS solution is that it can provide connectivity to both bridge and non-bridge types of CE devices. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks today or the same level of service that they receive from their Ethernet Service Providers using IEEE 802.1ad-based networks [P802.1ad] (or its predecessor, QinQ-based network). When CE devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. Majority of these issues have currently been addressed in IEEE 802.1ad standard for provider bridges and they need to be addressed for VPLS networks. This draft discusses these issues and wherever possible, the recommended solutions to these issues. "Virtual Private Lan Services (VPLS) Management Information Base", Thomas Nadeau, Kiran Koushik, 25-Feb-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 Pswudo Wire (PW) Management Information Base [PWE3-PW-MIB]. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Eric Rosen, 8-Aug-05, In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets traveling from one Provider Edge (PE) router to another generally carry two MPLS labels, an "inner" label that corresponds to a VPN- specific route, and an "outer" label that corresponds to a Label Switched Path (LSP) between the PE routers. In some circumstances, it is desirable to support the same type of VPN architecture, but using an IPsec Security Association in place of that LSP. The "outer" MPLS label would thus be replaced by an IP/IPsec header. This enables the VPN packets to be carried securely over non-MPLS networks, using standard IPsec authentication and/or encryption functions to protect them. This draft specifies the procedures which are specific to support of BGP/MPLS IP VPNs using the IPsec encapsulation. "Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Sarveshwar Bandi, Yiqun Cai, Thomas Morin, Yakov Rekhter, Eric Rosen, IJsbrand Wijnands, Seisho Yasukawa, 14-Jan-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, 19-Nov-07, 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, 7-Apr-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. Enhancements to Internet email to Support Diverse Service Environments (lemonade) --------------------------------------------------------------------------------- "IMAP CONVERT extension", Alexey Melnikov, Peter Coates, 1-Apr-08, CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences or its settings. "Support for Sieve in Internet Message Access Protocol (IMAP4)", Barry Leiba, 21-Feb-08, Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications).Note While this document defines extensions to IMAP and Sieve, it is the work of the Lemonade Working Group (Enhancements to Internet email to support diverse service environments), and discussion of it is on the lemonade mailing list at mailto:lemonade@ietf.org. Subscription requests can be sent to mailto:lemonade-request@ietf.org?body=subscribe (send an email message with the word "subscribe" in the body). A WWW archive of back messages is available at http://www.ietf.org/mail-archive/web/lemonade/index.html "Lemonade Notifications Architecture", Randall Gellens, Stephane Maes, 24-Feb-08, This document discusses how to provide notification and filtering mechanisms to IMAP 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 August 2008 Internet Draft Lemonade Notifications Architecture February 2008 "The Lemonade Profile", Dave Cridland, Alexey Melnikov, Stephane Maes, 21-Feb-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. "Deployment Considerations for lemonade-compliant Mobile Email", Randall Gellens, 20-Jun-07, This document discusses deployment issues and describes requirements for successful deployment of mobile email which are implicit in the IETF lemonade documents. "Internet Message Store Events", Randall Gellens, Chris Newman, 9-Jan-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. "Streaming Internet Messaging Attachments", Neil Cook, 27-Feb-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 4722). The document also defines a new IMAP METADATA entry. "The IMAP NOTIFY Extension", Curtis King, 24-Mar-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 OMA Mobile Email (MEM) using Internet Mail", Eric Burger, Glenn Parsons, 29-Dec-07, This document specifies the architecture for mobile email, as described by the OMA, using Internet Mail protocols. This architecture is the basis of the work of the LEMONADE WG and is a guideline for the LEMONADE Profile. Long-Term Archive and Notary Services (ltans) --------------------------------------------- "Long-term Archive Protocol (LTAP)", Aleksej Jerman-Blazic, Peter Sylvester, Carl Wallace, 25-Feb-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. "Using SCVP to Convey Long-term Evidence Records", Carl Wallace, 14-Feb-08, The Simple Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support non-repudiation of existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust in the certificates can be established after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes an application of SCVP to serve this purpose using the WantBack feature of SCVP to convey evidence records. "Validation and long term verification data for Evidence Records and signed documents", Tobias Gondrom, 16-Nov-07, Digitally signed documents and data in a LTANS service receive the signature renwal procedures and non-repudiation services. As documents can be stored for very long (theoretically inifinite) times, it is very important to understand which data is and will be necessary for the verification of the contained digital signatures and the applied timestamps and the evidence records. This document shall describe various pieces of information which SHOULD and MUST be provided to effectively verify evidence records and their protected data and signatures. "Extensible Markup Language Evidence Record Syntax", A. Jerman Blazic, Jerman Blazic, Tobias Gondrom, 3-Dec-07, In many scenarios, users must be able to demonstrate the (time) existence, integrity and validity of data including signed data for long or undetermined period of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence of data. ERS-XML incorporates alternative syntax and processing rules to ASN.1 ERS syntax by using XML language. "Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC)", Thomas Kunz, Susanne Okunick, Ulrich Pordesch, 10-Mar-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 used cryptographic algorithms. Because algorithms can become weak over the years, it is necessary to periodically evaluate these security suitabilities. When signing or verifying data, these evaluations must be considered. This document specifies a data structure for security suitabilities of cryptographic algorithms which may be automatically interpreted. Language Tag Registry Update (ltru) ----------------------------------- "Tags for Identifying Languages", Addison Phillips, Mark Davis, 17-Mar-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, 8-Feb-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) -------------------------------------------- "IGMPv3/MLDv2 and Multicast Routing Protocol Interaction", Brian Haberman, Jay Martin, 27-Oct-03, The definitions of IGMPv3 and MLDv2 require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates multicast routing protocols to manage and utilize the information. This document will describe how multicast routing protocols will interact with these source-filtering group management protocols. "Multicast Group Membership Discovery MIB", Julian Chesterfield, 4-Dec-07, 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, 9-Apr-08, The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile nodes 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, 25-Feb-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 takes advantage 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. 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, 25-Feb-08, This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for mobile ad hoc networks. 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 of OLSRv2 is that of multipoint relays, 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 diffuse 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 well in this context. "Generalized MANET Packet/Message Format", Thomas Clausen, Christopher Dearlove, Justin Dean, Cedric Adjih, 10-Mar-08, This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing and signaling protocols. "MANET Neighborhood Discovery Protocol (NHDP)", Thomas Clausen, Christopher Dearlove, Justin Dean, 10-Mar-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, 19-Nov-07, This document describes a general and flexible TLV (type-length-value structure) for representing time 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. MBONE Deployment (mboned) ------------------------- "Unicast-Prefix-based IPv4 Multicast Addresses", Dave Thaler, 25-Feb-08, This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based assignment of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. "Overview of the Internet Multicast Addressing Architecture", Pekka Savola, 19-Oct-06, The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. "AAA Framework for Multicasting", Hiroaki Satou, 25-Feb-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 (if not authenticate, especially within the context of enforcing electronic payment schemes) and to invoice such customers in a reliable and efficient manner. 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 draft-ietf-mboned-maccnt-req-04.txt, "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services". 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, 20-Nov-07, 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, 21-Feb-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, Tatsuya Jinmei, Bill Fenner, Stephen Casner, 12-Nov-07, 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 new router functionality. Media Server Control (mediactrl) -------------------------------- "Media Control Channel Framework", Chris Boulton, Tim Melanchuk, Scott McGlashan, 22-Feb-08, This document describes a Framework and protocol for application deployment where the application logic and processing are distributed. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and 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, 6-Feb-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, 16-Jan-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. Mobility EXTensions for IPv6 (mext) ----------------------------------- "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", Hesham Soliman, 20-Nov-07, 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 HA. 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. "Analysis of Multihoming in Mobile IPv6", Nicolas Montavont, Ryuji Wakikawa, Thierry Ernst, Chan-Wah Ng, Koojana Kuladinithi, 19-Nov-07, Mobile IPv6 as specified in RFC 3775 allows a mobile node to maintain its IPv6 communications while moving between subnets. This document investigates configurations where a mobile node running Mobile IPv6 is multihomed. The use of multiple addresses is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile nodes which are more prone to failure or sudden lack of connectivity. However, Mobile IPv6 currently lacks support for such multihomed nodes. The purpose of this document is to detail all the issues arising through the operation of Mobile IPv6 on multihomed mobile nodes. "Multiple Care-of Addresses Registration", Thierry Ernst, Kenichi Nagami, Vijay Devarapalli, 24-Feb-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, 19-Nov-07, The home agent can be a single point of failure when Mobile IPv6 is used 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", Kuntal Chowdhury, 25-Feb-08, This document defines new attributes to facilitate Mobile IPv6 operationrs using RADIUS infratstructure. The operations include bootstrapping of information required by the Mobile and the interface between the Home Agent and the RADIUS server used to assist MIP6 operations. "Generic Notification Message for Mobile IPv6", Brian Haley, Sri Gundavelli, 12-Oct-07, This document specifies a new Mobility Header message type that allows Mobile IPv6 entities to send and receive generic notification messages. "NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", Wesley Eddy, Will Ivancic, Terry Davis, 24-Feb-08, This document describes the requirements and desired properties of NEMO Route Optimization techniques for use in global networked communications systems for aeronautics and space exploration. This version has been reviewed by members of the International Civil Aviation Orgnanization (ICAO) and other aeronautical communications standards bodies, and contributed to by a number of aeronautical communications experts outside the normal IETF process. "AAA Goals for Mobile IPv6", Gerardo Giaretta, Ivano Guardini, Elena Demaria, Julien Bournelle, Rafa Lopez, 27-Dec-07, 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 (DSMIPv6)", Hesham Soliman, 25-Feb-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, 15-Feb-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, Massimiliano Lenardi, 18-Feb-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 for IPv4 (mip4) ------------------------ "IP Mobility Support for IPv4, revised", Charles Perkins, 11-Mar-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. "Mobile IPv4 Traversal Across IPsec-based VPN Gateways", Sami Vaarala, Espen Klovning, 14-Mar-08, This document outlines a solution for the Mobile IPv4 and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. "Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE", Vijay Devarapalli, Pasi Eronen, 5-Mar-07, Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. "Dual Stack Mobile IPv4", George Tsirtsis, Vincent Park, Hesham Soliman, 13-Feb-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. "Network Mobility (NEMO) Extensions for Mobile IPv4", Kent Leung, Gopal Dommety, Vidya Narayanan, Alexandru Petrescu, 11-Mar-08, This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the mobile network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. "Generic Notification Message for Mobile IPv4", Hui Deng, Henrik Levkowetz, Vijay Devarapalli, Sri Gundavelli, Brian Haley, 12-Feb-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, 6-Nov-07, The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism. "FA extensions to NEMOv4 Base", George Tsirtsis, Vincent Park, Vidya Narayanan, Kent Leung, 15-Feb-08, The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. NEMOv4 extensions are defined for use only by the mobile node and the home agent. This specification introduces extensions for NEMO support on the foreign agent. Mobility for IPv6 (mip6) ------------------------ "Using IPsec between Mobile and Correspondent IPv6 Nodes", Francis Dupont, Jean-Michel Combes, 23-Feb-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, 25-Feb-08, Mobile IPv6 defines a set of messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec SA that is established between the MN and HA. The MIP6 working group has 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 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, 9-Jul-07, 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 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, 7-Apr-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) -------------------------------------------------------------------------- "Mobile IPv6 Fast Handovers over IEEE 802.16e Networks", Hee-Jin Jang, Junghoon Jee, Youn-Hee Han, Soohong Daniel Park, Jaesun Cha, 10-Mar-08, This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications. The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the Mobile IPv6 fast handover procedures efficiently. "Mobile IPv6 Fast Handovers for 3G CDMA Networks", Hidetoshi Yokota, Gopal Dommety, 31-Mar-08, Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node moves between access routers. However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a new care-of address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network. During this period, packets destined for the mobile node may be lost, which may not be acceptable for real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover. "Mobile IPv6 Fast Handovers", Rajeev Koodli, 25-Feb-08, Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from an Access Router to another, a process referred to as handover. During this time, the Mobile Node is unable to send or receive packets due to both link switching delay and IP protocol operations. The "handover latency" resulting from standard Mobile IPv6 procedures, namely, movement detection, new Care of Address configuration and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. "Distributing a Symmetric FMIPv6 Handover Key using SEND", James Kempf, 31-Oct-07, Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a Mobile Node in order to avoid certain attacks. In this document, a method for provisioning a shared key from the Access Router to the Mobile Node is defined to protect this signaling. The Mobile Node generates a public/private key pair using the same public key algorithm as for SEND (RFC 3971). The Mobile Node sends the public key to the Access Router. The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node. The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update. The Mobile Node and Access Router use the Router Solicitation for Proxy Advertisement and Proxy Router Advertisement from Fast Mobile IPv6 for the key exchange. The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address and the messages are signed using the CGA private key of the sending node. This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key. "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", Claude Castelluccia, 8-Apr-08, This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. "Mobility Services Framework Design", Telemaco Melia, Gabor Bajko, Subir Das, Nada Golmie, Zhongqi Xia, Juan Zuniga, 12-Feb-08, This document describes a design solution for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document describes mechanisms for mobility service (MoS) discovery and transport layer mechanisms for the reliable delivery of MIH messages. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Real Time Streaming Protocol 2.0 (RTSP)", Henning Schulzrinne, Anup Rao, Rob Lanphier, Magnus Westerlund, Martin Stiemerling, 25-Feb-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, 25-Feb-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, 15-Nov-07, 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, 23-Jan-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, 25-Feb-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-Martin, Markus Isomaki, Gonzalo Camarillo, Salvatore Loreto, Paul Kyzivat, 27-Mar-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-Dec-07, 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 and its current extensions do 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, Flemming Andreasen, 24-Feb-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. "Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)", James Polk, Subha Dhesikan, Gonzalo Camarillo, 24-Jan-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, 25-Feb-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, 25-Feb-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 RTP payload type(s). "SDP: Session Description Protocol", Mark Handley, 17-Dec-07, 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, 17-Jan-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. "Session Description Protocol (SDP) Indicators for Datagram Transport Layer Security (DTLS)", Jason Fischl, Hannes Tschofenig, 23-Jan-08, This specification defines how to use the Session Description Protocol (SDP) to signal that media will be transported over Datagram Transport Layer Security (DTLS) or where the SRTP security context is established using DTLS and. It reuses the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate which will be presented during the DTLS handshake. Multiprotocol Label Switching (mpls) ------------------------------------ "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", Riza Cetin, 19-Nov-07, 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, 18-Feb-08, This document details 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 preemption pending flag helps more gracefully mitigate the re-route process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be re-routed. For this reason, the feature is primarily but not exclusively interesting in MPLS enabled IP networks with Differentiated Services and Traffic Engineering capabilities. "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, 28-Oct-07, 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 recognised and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS 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", Anca Zamfir, 2-Apr-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 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. "MPLS Multicast Encapsulations", Toerless Eckert, Eric Rosen, Rahul Aggarwal, Yakov Rekhter, 2-Nov-07, RFC 3032 established two data link layer codepoints for MPLS: one to indicate that the data link layer frame is carrying an MPLS unicast packet, and the other to indicate that the data link layer frame is carrying an MPLS multicast packet. This specification updates RFC 3032 by redefining the meaning of these two codepoints. The former "multicast codepoint" is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label". The former "unicast codepoint" is to be used in all other cases. Whether the data link layer payload is a unicast MPLS packet or a multicast MPLS packet is now to be determined by looking up the top label, rather than by the codepoint. RFC 3032 does not specify the destination address to be placed in the "MAC DA" field of an ethernet frame which carries an MPLS multicast packet. This document provides that specification. This document updates RFC 3032 and RFC 4023. "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Ina Minei, 22-Feb-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. The solution relies on LDP without requiring a multicast routing protocol in the network. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/MP2MP LSP is outside the scope of this document. "MPLS Upstream Label Assignment and Context-Specific Label Space", Rahul Aggarwal, Yakov Rekhter, Eric Rosen, 22-Feb-08, RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". "MPLS Upstream Label Assignment for RSVP-TE", Rahul Aggarwal, Jean-Louis Le Roux, 18-Nov-07, 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, 19-Nov-07, 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. "Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol", Jean-Louis Le Roux, 25-Feb-08, This document lists a set of functional requirements for Label Distribution Protocol (LDP) extensions for setting up point-to- multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. It is intended that solutions that specify LDP procedures for setting up P2MP LSP satisfy these requirements. "A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link", JP Vasseur, Matthew Meyer, Kenji Kumaki, Alberto Bonda, 6-Feb-08, Several Link-type sub-TLVs have been defined for OSPF and IS-IS in the context of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group and so on. By making statistical assumption about the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwith (referred to as unconstrained TE LSP in this document), and with the knowledge of the number of unconstrained TE LSPs signalled across a link, algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths. This requires knowledge of the number of unconstrained TE LSPs signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSP(s) signalled across a link. "Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module", Adrian Farrel, Seisho Yasukawa, Thomas Nadeau, 14-Feb-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. "LDP Typed Wildcard FEC", Bob Thomas, Ina Minei, 26-Mar-08, The LDP specification [RFC5036] for the Wildcard FEC element has several deficiencies. This document corrects those deficiencies. In addition, it specifies the Typed Wildcard FEC for the Prefix FEC Element Type defined in RFC5036. "Proxy LSP Ping", George Swallow, Vanson Lim, 19-Nov-07, 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. "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", Jean-Louis Le Roux, 27-Feb-08, This document defines procedures for fast reroute protection of Point-To-MultiPoint (P2MP) Traffic Engineering Label Switched Paths (TE-LSP) in MultiProtocol Label Switching (MPLS) networks, based upon Point-To-MultiPoint Bypass Tunnels. The motivation for using P2MP Bypass Tunnels is to avoid potentially expensive data duplication along the backup path that could occur if Point-To-Point Bypass Tunnels were used, i.e., to optimize the bandwidth usage, during fast reroute protection of a link or a node. During link or node failure the traffic carried onto a protected P2MP TE-LSP is tunnelled within one or several P2MP Bypass Tunnels towards a set of Merge Points. To avoid data duplication, backup labels (i.e., inner labels) are assigned by the Point of Local Repair (PLR) according to the RSVP-TE upstream label assignment procedure. "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-Feb-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. "LDP extension for Inter-Area LSP", Bruno Decraene, 25-Feb-08, To facilitate the establishment of Label Switched Paths (LSP) that would span multiple IGP areas in a given Autonomous System (AS), this document proposes a new optional label mapping procedure for the Label Distribution Protocol (LDP). This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the routing table (RIB). Matching is defined by an IP longest match search and does not mandate an exact match. "Security Framework for MPLS and GMPLS Networks", Luyuan Fang, 25-Feb-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. "An Analysis of Scaling Issues in MPLS-TE Backbone Networks", Seisho Yasukawa, Adrian Farrel, Olufemi Komolafe, 13-Oct-07, Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' backbone networks. As providers plan to grow these networks, they need to discover whether existing protocols and implementations can support the network sizes that they are planning. This document presents an analysis of some of the scaling concerns for MPLS-TE backbone networks, and examines the value of two techniques for improving scaling. 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", Markus Jork, Alia Atlas, Luyuan Fang, 24-Mar-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 traffic with packets carrying a label stack of more than one label or when the 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. Multicast Security (msec) ------------------------- "Multicast Extensions to the Security Architecture for the Internet Protocol", Brian Weis, George Gross, Dragan Ignjatic, 22-Feb-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. "On the applicability of various MIKEY modes and extensions", Steffen Fries, Dragan Ignjatic, 31-Mar-08, Multimedia Internet Keying - MIKEY - is a key management protocol that can be used for real-time applications. In particular, it has been defined focusing on the support of the Secure Real-time Transport Protocol. MIKEY itself is standardized within RFC3830 and defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arose, especially in terms of additional key distribution methods, but also in terms of payload enhancements. This document provides an overview about the MIKEY base document in general as well as the existing extensions for MIKEY, which have been defined or are in the process of definition. It is intended as additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general among them media before SDP answer, forking, and shared key conferencing. "Use of TESLA in the ALC and NORM Protocols", Vincent Roca, Aurelien Francillon, Sebastien Faurite, 18-Feb-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. Adding authentication/integrity verification to the packets sent by receivers, if any, is out of the scope of this document. "GDOI Key Establishment for the SRTP Data Security Protocol", Mark Baugher, Adrian-Ken Rueegsegger, Sheela Rowles, 4-Dec-07, The Secure Real-time Transport Protocol (SRTP) protects unicast and multicast RTP packets. Multicast receivers of SRTP session data therefore share an SRTP master key for message authentication and decryption. This document describes how to establish a shared, "group key" for an SRTP session using RFC 3547, the Group Domain of Interpretation (GDOI) and RFC 2408, the Internet Security Association and Key Management Protocol. This document extends GDOI for SRTP group key establishment. "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", David McGrew, Brian Weis, 15-Nov-07, 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) --------------------------------- "Network Endpoint Assessment (NEA): Overview and Requirements", Paul Sangster, 25-Feb-08, This document defines the problem statement, scope and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g. an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out of date security protective mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced. "PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC", Ravi Sahita, Stephen Hanna, Ryan Hurst, 4-Apr-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. Network Mobility (nemo) ----------------------- "DHCPv6 Prefix Delegation for NEMO", Ralph Droms, Pascal Thubert, 6-Dec-07, One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. Network Configuration (netconf) ------------------------------- "NETCONF Event Notifications", Sharon Chisholm, Hector Trevino, 25-Feb-08, This document defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. "NETCONF over Transport Layer Security (TLS)", Mohamad Badra, 15-Feb-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 Protocol (TLS) to secure NETCONF exchanges. "Partial Lock RPC for NETCONF", Balazs Lengyel, Martin Bjorklund, 25-Feb-08, The NETCONF protocol defines the lock and unlock RPCs that 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, 26-Feb-08, Today no standard method is defined to monitor the NETCONF protocol, including items such as sessions and subscription information. As NETCONF adds these and increasing capabilities which can impact configuration management, monitoring becomes increasingly important. This document defines NETCONF content via XML Schema to be used to monitor the Netconf protocol. It includes information about Netconf sessions, locks, and subscriptions and is intended to facilitate management of a NETCONF server. In addition this memo defines a mechanism to be able to discover all possible data models (XML Schemas) from a NETCONF server. This mechanism provides explicit references to supported schema versions and can be performed dynamically throughout a session, unlike capabilities exchange which is performed during session setup only. Network-based Localized Mobility Management (netlmm) ---------------------------------------------------- "Interface between a Proxy MIPv6 Mobility Access Gateway and a Mobile Node", Julien Laganier, Sathya Narayanan, Peter McCann, 13-Feb-08, This document describes an interface between mobile nodes (MNs) and a mobility access gateway (MAG) of a network-based localized mobility management (NETLMM) domain. The interface has two functions which are invoked when a MN attaches and detaches from a MAG. The attachment function lets the MAG authenticate the MN identifier, does address(es) and default router configuration for the MN, and informs the MAG about the multicast listener state of the MN. During the attachment function the NETLMM protocol is triggered between the MAG and Localized Mobility Anchor (LMA) to register the MN in the local domain. The detachment function lets the MAG detect that the MN has left so that it can deregister the MN at the LMA using the NETLMM protocol. "Proxy Mobile IPv6", Sri Gundavelli, Kent Leung, Vijay Devarapalli, Kuntal Chowdhury, Basavaraj Patil, 24-Feb-08, Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility related signaling. The Network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6. "IPv4 Support for Proxy Mobile IPv6", Ryuji Wakikawa, Sri Gundavelli, 19-Nov-07, This document specifies extensions to Proxy Mobile IPv6 protocol for supporting IPv4 protocol. The scope of this IPv4 support includes the support for the mobile node's IPv4 home address mobility and for allowing the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over IPv4 transport. The solution leverages the extensions defined in DSMIPv6 specification for achieving this. Network File System Version 4 (nfsv4) ------------------------------------- "RPC: Remote Procedure Call Protocol Specification Version 2", Robert Thurlow, 22-Feb-08, This document describes the ONC (Open Network Computing) Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. It is meant to supersede [RFC1831]. "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, 24-Feb-08, A protocol is described providing Remote Direct Memory Access (RDMA) as a new transport for Computing 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, 24-Feb-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, 25-Feb-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, 2-Apr-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, 1-Apr-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-21. "NFSv4 Minor Version 1 XDR Description", Spencer Shepler, Mike Eisler, David Noveck, 25-Feb-08, This Internet-Draft provides the XDR description for NFSv4 minor version one. "RPCSEC_GSS Version 2", Mike Eisler, 24-Feb-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. Individual Submissions (none) ----------------------------- "Internet Email Subaddressing", Dave Cridland, 16-Nov-07, It is often useful for a single user to have multiple email addresses which can be used to assist categorizing incoming email. One way of doing this is to divide the local-part of an email address into user and detail parts. The user part is used to route the message within the specified domain and the detail part is used to route the message according to a particular user's wishes. This specification formalizes the de-facto standard for subaddressing in use today and includes advice and requirements for final delivery agents, MUAs and mail list servers which wish to support subaddressing. "Salted Challenge Response Authentication Mechanism (SCRAM)", Chris Newman, 14-Dec-07, 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 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, this mechanism 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. "Geographic registration of HTML documents", Andrew Daviel, Felix Kaegi, 31-Oct-07, This memo describes a method of registering HTML documents with a specific geographic location through means of embedded META tags. The content of the META tags gives the geographic position of the resource described by the HTML document in terms of Latitude, Longitude, and optionally Elevation in a simple, machine-readable manner. This information may be used for automated resource discovery by means of an HTML indexing agent or search engine. META tags giving a civic location of a resource are also described. "Additional ECC Groups For IKE and IKEv2", Daniel R. L. Brown, 10-Oct-06, This document describes additional elliptic curve groups for use in IKE (as defined in RFC 2409) and IKEv2 (as defined in RFC 3406). These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, and in addition, many of them provide higher strength than the previousley defined Oakley groups. "Geographic extensions for HTTP transactions", Andrew Daviel, Felix Kaegi, Martin Kofahl, 7-Dec-07, This memo describes a method of adding simple geographic position or region information to HTTP transactions using extension headers. It allows location-based services on the World Wide Web, without the additional overhead of geographic query requests and possibly graphical input. Extension headers transmit predefined or detected position information to reflect a location that the requesting agent is interested in. This information may be used by a server to present appropriate position-dependent responses, such as search engine results or weather maps. "Cisco Systems' Simple Certificate Enrollment Protocol(SCEP)", Xiaoyi Liu, 3-Dec-07, 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, 20-Nov-07, 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. "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. "IPv4 Address Conflict Detection", Stuart Cheshire, 20-Feb-08, When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination) problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect after-the-fact that it has happened, so that the host or administrator may respond to rectify the problem. "URI Scheme for GSM Short Message Service", Erik Wilde, Antti Vaha-Sipila, 18-Dec-07, 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. "Media Gateway Control Protocol Fax Package", Flemming Andreasen, David Hancock, 20-Feb-08, This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement. "Analysis of Inter-Domain Routing Requirements and History", Avri Doria, Elwyn Davies, 7-Jan-08, This document analyses the state of Inter-Domain Routing (IDR) and 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 as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "Requirements for Inter-Domain Routing" [I-D.irtf-routing-reqs], which is a discussion of requirements for the future routing architecture and future routing protocols. 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.] "Instructions to Request for Comments (RFC) Authors", Joyce Reynolds, Robert Braden, 20-Jul-04, This memo provides information for authors of Request for Comments (RFC) documents. It summarizes RFC editorial policies and formatting requirements, addresses frequently-asked questions, and serves as a model for constructing a properly formatted RFC. "Mobile SCTP", Maximilian Riegel, Michael Tuexen, 5-Nov-07, Transport layer mobility management is presented in addition to Mobile IP for providing seamless mobility in the Internet. By use of SCTP (Stream Control Transmission Protocol) and some of its currently proposed extensions a seamless handover can be fully accomplished in the mobile client without any provisions in the network, only assisted by functions embedded in Mobile SCTP enabled servers. Client mobility management based on Mobile SCTP seems not to require any new protocol development. It is a particular application of SCTP eventually solving the requirements of transport layer mobility in the Internet. "IMAP METADATA Extension", Cyrus Daboo, 22-Dec-07, 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. "Web Distributed Authoring and Versioning (WebDAV) SEARCH", Julian Reschke, Surendra Reddy, Jim Davis, Alan Babich, 18-Feb-08, This document specifies a set of methods, headers, properties and content-types composing WebDAV SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. "An IPv4 Flowlabel Option", Thomas Dreibholz, 9-Jan-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. "Dynamic Hostname Exchange Mechanism for OSPF", Subbaiah Venkata, Sanjay Harwani, Carlos Pignataro, Danny McPherson, 29-Jan-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. "URI Fragment Identifiers for the text/plain Media Type", Erik Wilde, Martin Duerst, 1-Nov-07, This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range. Fragment identifiers may also contain information for integrity checks to make them more robust. "Using PPP-over-Ethernet (PPPoE) in Wireless LANs", Giuseppe Paterno, 26-May-05, This document explores the use of Point-To-Point Protocol over Ethernet (PPPoE) to provide wireless access to the Internet and suggests how the infrastructure can be deployed. The document targets consumers, corporations, Internet Service Providers, and mobile phone operators that provide user access through Wireless LANs technologies such as IEEE 802.11. "EAP-Support in Smartcard", Guy Pujolle, Pascal Urien, 20-Feb-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 Mandating the Use of IPsec Version 2", Steven Bellovin, 8-Oct-07, 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, 16-Nov-07, This document describes Split Multi-link Trunking (SMLT) for bridged and routed networks. SMLT enables topologies with upstream node redundancy for increased reliability of Layer 2 link aggregation subnetworks based on [IEEE 802.3ad] and router redundancy based on VRRP [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. "Reorder Density and Reorder Buffer-occupancy Density - Metrics for Packet Reordering Measurements", Anura Jayasumana, 23-Jul-07, This document presents two metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density (RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory. requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering. These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication. "Reliable Server Pooling Applicability for IP Flow Information Exchange", Lode Coene, 9-Jan-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. "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis, 25-Feb-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. "Memorandum for multi-domain Public Key Infrastructure Interoperability", Masaki Shimaoka, Nelson Hastings, Rebecca Nielsen, 1-Apr-08, The objective of this document is to establish a terminology framework and to suggest the operational requirements of PKI domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi-domain PKI. "Requirements for Inter-Domain Routing", Avri Doria, 7-Jan-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, 11-Mar-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. "A Bound End-to-End Tunnel (BEET) mode for ESP", Pekka Nikander, Jan Melen, 12-Nov-07, This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. "An information model for Kerberos version 5", Leif Johasson, 12-Nov-07, 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. "Session Initiation Protocol (SIP) Event Notification Extension for Notification Throttling", Aki Niemi, Krisztian Kiss, 25-Feb-08, This memo specifies a throttle mechanism for limiting the rate of Session Initiation Protocol (SIP) event notifications. This mechanism can be applied in subscriptions to all SIP event packages, but the mechanism is especially designed to be used in combination with a subscription to a Resource List Server (RLS). "PATCH Method for HTTP", Lisa Dusseault, James Snell, 3-Jan-08, Several applications extending HTTP require a feature to do partial resource modification. Existing HTTP functionality only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. "MANET Extension of OSPF using CDS Flooding", Richard Ogier, Phil Spagnolo, 18-Nov-07, This document specifies an extension of OSPF for IPv6 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new LSAs back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. "UDT: UDP-based Data Transfer Protocol", Yunhong Gu, Robert Grossman, 11-Oct-07, This document proposes UDT, or UDP based Data Transfer protocol, as an alternative data transfer protocol for the situation when TCP does not work well. One of the most common cases, and also the original motivation of UDT, is to overcome TCP's inefficiency in high bandwidth-delay product (BDP) networks. Another important target use scenario is to allow networking researchers, students, and application developers to easily implement and deploy new data transfer algorithms and protocols. "SixXS Heartbeat Protocol", Jeroen Massar, 6-Jun-05, This document proposes a heartbeat protocol for signalling availability of hosts with a specific emphasis on providing a signalling protocol for allowing dynamic non-24/7 endnodes to use tunnel's of the various IPv6 Tunnel Brokers. "Mixmaster Protocol Version 2", U Moeller, 30-Dec-04, Most e-mail security protocols only protect the message body, leaving useful information such as the identities of the conversing parties, sizes of messages and frequency of message exchange open to adversaries. This document describes Mixmaster version 2, a mail transfer protocol designed to protect electronic mail against traffic analysis. "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", Florent Parent, Marc Blanchet, 2-Sep-05, A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6 or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP protocol within the model of the tunnel broker model. "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Cornelia Kappler, Xiaoming Fu, Bernd Schloer, 1-Feb-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. "Terminology for Benchmarking LDP Data Plane Convergence", Thomas Eriksson, 19-Feb-08, This document defines new terms for benchmarking of LDP convergence. These terms are to be used in future methodology documents for benchmarking LDP Convergence. Existing BMWG terminology documents such as IGP Convergence Benchmarking [3] provide useful terms for LDP Convergence benchmarking. These terms are discussed in this document. Applicable terminology for MPLS and LDP defined in MPLS WG RFCs [1] and [2] is also discussed. "Iowa Internet Annoyance Logging Protocol (IIALP) pronounced E'-alp", George Davey, 23-Oct-07, This draft describes a system by which Internet Annoyances can be logged quickly and automatically using IIALP (Iowa Internet Annoyance Logging Protocol). The annoyance logs on a particular IIALP Server are condensed and forwarded up the IIALP hierarchy to central Root IIALP Servers for central annoyance queries. Serial numbers and TTL values keep the individual reports organized and dated. One unique complaint per IP per epoch period prevents flooding. Differences in detail and propagation parameters exist between Root and Subordinate IIALP Servers to allow for more detail to be kept at the originating IIALP Server. Standard XML and TCP security techniques, and Hierarchy Structure eliminate erroneous reporting. Routers and software running IIALP can use IIALP to create dynamic QOS lists for abusing Internet assets exceeding a set limits. IIALP allows for an infinite number of different types of annoyances to exist but has concise templates for common annoyances such as SPAM. IIALP is a centralized logging system for Internet annoyance event reporting. "User Session Tracking in RADIUS", Glen Zorn, Avi Lior, 21-Feb-08, This document defines a set of new messages and attributes designed to allow RADIUS servers to cleanly track user sessions. "Guidelines for Management of DNSBLs for Email", Chris Lewis, Matt Sergeant, 7-Apr-08, The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists of IPs or domains used to help guide email filtering. This memo discusses guidelines for management of public DNSBLs by the operators of such DNSBLs, as well as provide useful background for server administrators who use DNSBLs. It is not intended to advise on the utility or effiacacy 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, 21-Feb-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. "Licklider Transmission Protocol - Specification", Manikantan Ramadas, Scott Burleigh, Stephen Farrell, 20-Jan-08, This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but it has applications in other environments as well. LTP does ARQ of data transmissions by soliciting selective- acknowledgment reception reports. It is stateful, and has no negotiation or handshakes. In an Interplanetary Internet setting deploying the Bundle protocol that is being developed by the Delay Tolerant Networking Research Group, LTP is intended to serve as a reliable "convergence layer" protocol operating in pairwise fashion between adjacent Interplanetary Internet nodes that are in direct RF communication. In that operational scenario, and potentially in some other deployments of the Bundle Protocol, LTP runs directly over a data- link layer protocol; when this is the case, forward error correction coding and/or checksum mechanisms in the underlying data-link layer protocol must assure the integrity of the data passed between the communicating entities. Since no mechanisms for flow control or congestion control are included in the design of LTP, this protocol is not intended or appropriate for ubiquitous deployment in the global Internet. When LTP is run over UDP, it must only be used for software development or in private local area networks. When LTP is not run over UDP, it must be run directly over a protocol, (nominally a link- layer protocol), that meets the requirements specified in section 5. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. "Internet Mail Architecture", Dave Crocker, 24-Feb-08, Over its thirty-five year history Internet Mail has undergone significant changes in scale and complexity, as it has become a global infrastructure service. The first standardized architecture for networked email specified little more than a simple split between the user world and the transmission world. Core aspects of the service, such as the styles of mailbox address and basic message format, have remained remarkably constant. However today's Internet Mail is distinguished by many independent operators, many different components for providing service to users and many others for performing message transfer. Public discussion of the service often lacks common terminology and a common frame of reference for these components and their activities. Having a common reference model and terminology facilitates discussion about problems with the service, changes in policy, or enhancement to the service's functionality. This document offers an enhanced Internet Mail architecture that targets description of the existing service, in order to facilitate clearer and more efficient technical, operations and policy discussions about email. "Population Count Extensions to PIM", Dino Farinacci, Greg Shepherd, 27-Feb-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. "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. "The case against Hop-by-Hop options", Suresh Krishnan, 25-Feb-08, The Hop-by-Hop option header is a type of IPv6 extension header that has been defined in the IPv6 protocol specification. The contents of this header need to be processed by every node along the path of an IPv6 datagram.This draft highlights the characteristics of this extension header which make it prone to Denial of Service attacks and proposes solutions to minimize such attacks. "Session Key Transport in RADIUS", Glen Zorn, Hao Zhou, Joseph Salowey, 21-Feb-08, This document describes an extension to the RADIUS protocol designed to support requests for, and delivery of, session key material between RADIUS clients and servers. The messages described in this document may be used for a wide variety of keying applications. "RADIUS Attributes for 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, 9-May-05, This document describes a method for increasing the space available for TCP options. Two new TCP options (LO and SLO) are detailed which reduce the limitations imposed by the TCP header's Data Offset field. The LO option provides this extension after connection establishment, and the SLO option aids in transmission of lengthy connection initialization and configuration options. "TLS Express", Mohamad Badra, 16-Feb-05, This document defines a new extension that may be used to add Pre Shared Key authentication functionality to TLS. It is based on the TLS abbreviated handshake and it provides the ability to share a session key for data encryption. "Securing Neighbour Discovery Proxy Problem Statement", Greg Daley, Jean-Michel Combes, 25-Feb-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. "Group Co-operative Route Filtering capability for BGP-4", Susan Hares, Praveen Muley, Keyur Patel, Benson Schliesser, 24-Feb-08, Currently BGP-4 is capable of carrying multiple (Outbound Route Filters) ORFs entries for a given "AFI/SAFI". Each ORF provides a filter that a route whose NLRI matches AFI/SAFI, must pass through to be transmitted in the BGP Update message. Efficient processing of ORF filters may require ordering of individual ORFs in certain sequence and grouping of ORFs that should be applied together. The grouping functionality also provides the support for logical OR operation between the grouped ORFs. This group ORF provides an ORF type that specifies that ordering and grouping. The route set that passes set of ORFs running in a "Group ORF" will pass the same ORFs sent in normal ORFs. "Mobile IPv6 - NSIS Interaction for Firewall traversal", Niklas Steinleitner, Xiaoming Fu, Franck Le, 16-Nov-07, Most of the firewalls deployed today are Mobile IPv6 unaware. Widespread Mobile IPv6 deployment is not possible unless Mobile IPv6 messages can pass through these firewalls. One approach is to use a signaling protocol to communicate with these firewalls and instruct them to bypass these Mobile IPv6 messages. The goal of this document is to describe the interaction between NSIS and Mobile IPv6 for enabling Mobile IPv6 traversal. "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. "Document: draft-otani-ccamp-interas-gmpls-te-07.txt", Tomohiro Otani, Shuichi Okamoto, Satoru Okamoto, 18-Dec-07, This draft provides requirements for the support of generalized multi-protocol label switching (GMPLS) inter-domain traffic engineering (TE). Its main objective is to present the differences between MPLS inter-domain TE and GMPLS inter-domain TE. This draft covers not only GMPLS Inter-domain architecture but also functional requirements in terms of GMPLS signaling and routing in order to specify these in a GMPLS Inter-domain environment. "Scope Modifiers in Intellectual Property Declarations", I Maturana, I Robredo, 16-Aug-05, The purpose of this RFC is to focus discussion on intellectual property problems in the Internet. This document introduces and defines scope modifiers to be used in intellectual property declarations. These modifiers abstract the ownership behavior of resources available in interoperable environnments, such as the Internet. "A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Datasets", Sumanth Channabasappa, Sam Ganesan, 18-Nov-07, 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. It also explores some specific datasets to test the requirements, assumptions and syntax. "Using XML Schema to define NETCONF Content", Sharon Chisholm, Alex Clemm, 25-Feb-08, This memo defines a framework for defining content for NETCONF using a meta-model and XML Schema. The approach is to build on existing well-deployed technology and overlap management specific semantics to ensure high-quality interoperable definition of NETCONF content. "Guidelines for Writing an IANA Considerations Section in RFCs", Thomas Narten, Harald Alvestrand, 26-Mar-08, Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned, or when modifications to existing values can be made. If IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on IANA. This document obsoletes RFC 2434. Contents Status of this Memo.......................................... 1 "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)". "Guidelines for an Arabic Domain Name System (ADNS)", Mansour Farah, 9-Nov-07, There have been several attempts aimed at developing an Arabic Domain Name System (ADNS) using Arabic characters in an Arabic-language coherent fashion. In the beginning of the second quarter of 2003, an Arabic Domain Name Task Force (ADNTF) was formed under the auspices of United Nations Economic and Social Commission for Western Asia (ESCWA), and the guidance of Multilingual Internet Names Consortium (MINC); one of its main objectives was to help define standards for ADNS through a Request For Comments (RFC) document. This document resolves many technical and linguistic issues, including the adoption of the client-side DNS-based approach to name resolution; syntax of the proposed Arabic Domain Names together with the character set and many Arabic language-specific issues were clearly resolved. This Internet-Draft proposes guidelines that are compatible with the Internet Consortium for Assigned Names and Numbers (ICANN) and the Internet Engineering Task Force (IETF) as far as Domain Names System (DNS) and Internationalized Domain Names (IDN) standards are concerned. Technical, management, operational, and language-specific issues are discussed and recommendations are made. "Message Header Field for Indicating Message Authentication Status", Murray Kucherawy, 19-Mar-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. "Network-Layer Signaling: Transport Layer", Melinda Shore, 14-Jun-07, 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 to carry requests to middleboxes and other network devices. It is based on a "two-layer" architecture that divides protocol function into transport and application. This document describes the transport protocol. "Interaction between SIP and HIP", Hannes Tschofenig, Joerg Ott, Henning Schulzrinne, Tom Henderson, Gonzalo Camarillo, 25-Feb-08, This document investigates the interworking between the Session Initiation Protocol (SIP) and the Host Identity Protocol (HIP) and the benefits that may arise from their combined operation. The aspect of exchanging Host Identities (or Host Identity Tags) in SIP/SDP for later usage with the Host Identity Protocol Protocol (HIP) is described in more detail as an example of this interworking. "Using Kerberos V5 over the Transport Layer Security (TLS) protocol", Simon Josefsson, 3-Dec-07, This document specify how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol, to provide additional security features. "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", Joseph Touch, 27-Feb-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 "NAT/FW NSLP State Machine", Constantin Werner, Niklas Steinleitner, Xiaoming Fu, Hannes Tschofenig, Cedric Aoun, 9-Nov-07, This document describes the state machines for the NSIS Signaling Layer Protocol for Network Address Translation/Firewall signaling (NAT/FW NSLP). A set of state machines for NAT/FW NSLP entities at different locations of a signaling path are presented in order to illustrate how NAT/FW NSLP may be implemented. "Licklider Transmission Protocol - Motivation", Scott Burleigh, Manikantan Ramadas, Stephen Farrell, Intellectual Property, 9-Apr-08, This document describes the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but it has applications in other environments as well. In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serve as a reliable convergence layer over single hop deep-space RF links. LTP does ARQ of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. "Licklider Transmission Protocol - Security Extensions", Stephen Farrell, Manikantan Ramadas, Scott Burleigh, Intellectual Property, 12-Mar-08, The Licklider Transmission Protocol (LTP), is intended to serve as a reliable convergence layer over single hop deep-space RF links. LTP does ARQ of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. LTP is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but has applications in other environments as well. This document describes security extensions to LTP, and is part of a series of related documents describing LTP. Other documents in this series cover the motivation for LTP and the main protocol specification. We recommend reading all the documents in the series before writing code based on this document. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. "The OpenPGP mail and news header field", Atom Smasher, Simon Josefsson, 1-Apr-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, 13-Nov-07, This document defines a procedure which performs a "care-of address test" using a state cookie for routing optimization in Mobile IPv6 not protected by the routing routability procedure, i.e., protected by some alternative mechanisms like pre-shared secret or pre- established IPsec security associations. "TLS Sign", Ibrahim Hajjeh, Mohamad Badra, 15-Dec-07, TLS protocol provides authentication and data protection for communication between two entities. However, missing from the protocol is a way to perform non-repudiation service. This document defines extensions to the TLS protocol to allow it to perform non-repudiation service. It is based on [TLSSIGN] and it provides the client and the server the ability to sign by TLS, handshake and applications data using certificates such as X.509. "A Uniform Resource Name (URN) namespace for the Open Geospatial Consortium (OGC)", Carl Reed, 19-Oct-07, This document describes a Uniform Resource Name (URN) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC. The formal Namespace IDentifier (NID) is "ogc". "Certificate Exchange Messaging for EDIINT", Kyle Meadors, Dale Moberg, 22-Feb-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, 19-Nov-07, 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 aggregation 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. "RTCP XR VoIP Metrics Package for the Media Gateway Control Protocol", David Auerbach, 1-Nov-07, The main intent of this document is to define a Media Gateway Control Protocol (MGCP) package to control the reporting of metrics supported by the VoIP metrics block in RTCP Extended Reports as specified in [RFC 3611]. It also allows the call agent to control whether or not the gateway will request a peer device via SDP to send the VoIP metrics block in RTCP Extended Reports and whether it will respond positively to such requests from the peer device. Besides this primary focus, this package also allows the reporting of metrics defined for RTCP Sender Reports and Receiver Reports [RFC 3550] and the reporting of session description parameters (based on the ones defined in RFC 2327, RFC 2198 etc.). "VoIP Configuration Server Address Option", Richard Johnson, 16-Nov-07, 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 [6], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. "Circuit Cross-Connect", Kireeti Kompella, 9-Feb-06, Circuit Cross-Connect (CCC) was the ground-breaking design and implementation of the transport of Layer 2 frames over Multi-Protocol Label Switching (MPLS), which is now seen as an important application of MPLS. Thus, documenting CCC is important from a historical point of view. Furthermore, CCC is still in production in many networks, providing yet another reason to document it. It is hoped that those interested in this area will see where it started, how far we have come, and the strengths and weaknesses of this particular approach, and thereby gain some perspective of the area. If in the process they get new insights for the future development in this area, that is a bonus. "Session Initiation Protocol (SIP) over Datagram Transport Layer Security (DTLS)", Cullen Jennings, Nagendra Modadugu, 10-Oct-07, This specification defines how to use Datagram Transport Layer Security (DTLS) as a transport for Session Initiation Protocol (SIP). DTLS is a protocol for providing Transport Layer Security (TLS) security over a datagram protocol. This specification also specifies the IANA registrations for using SIP with Datagram Congestion Control Protocol (DCCP). DTLS can be used with either UDP or the Datagram Congestion Control Protocol (DCCP). To accommodate this, this specification also defines how to use SIP directly over DCCP. "Document: draft-otani-ccamp-gmpls-cspf-constraints-07.txt", Tomohiro Otani, Kenichi Ogaki, Arthi Ayyangar, Rajiv Papneja, Kireeti Kompella, Daniel King, 19-Nov-07, This document provides guidelines for the consideration of Generalized Multiprotocol Label Switching (GMPLS) Traffic-Engineering (TE) attributes for computation of routes for Label Switched Paths (LSPs) in a GMPLS network. This document summarizes how GMPLS TE attributes on ingress links, transit links, and egress links may be treated as path computation constraints to determine the route of a GMPLS Label Switched Path (LSP). T. Otani et al. Expires May 2008 1 Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt November 2007 "Transmitting Confidential Data in RADIUS", Glen Zorn, Hao Zhou, Joseph Salowey, 25-Feb-08, This document defines a set of RADIUS Attributes designed to allow the secure transmission of sensitive or confidential data between RADIUS clients and servers and the strong authentication of any RADIUS message. "Dynamic AS Re-Association At Confederation Edge", Susan Hares, Pratik Bose, 24-Feb-08, This document provides a mechanism for Autonomous Systems within an AS Confederation to survive the disconnection to other AS within the AS confederation without dropping peers. When all links to the other AS in the Confederation break, this mechanism allows the AS to revert to local AS to continue communication with E-BGP peers. This mechanism has two parts: Capability signaling between the two parties at connection start to save two AS (internal and AS Confederation AS) and a mechanism to signal the switch between AS Confederation AS and internal AS. "Session Initiation Protocol (SIP) Session Mobility", Ron Shacham, Henning Schulzrinne, Srisakul Thakolsri, Wolfgang Kellerer, 18-Nov-07, Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP). Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is intended as an informational document. "The 'mailto' URI Scheme", Martin Duerst, Larry Masinter, Jamie Zawinski, 24-Feb-08, This document defines the format of Uniform Resource Identifiers (URI) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with IRIs (RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", Shinta Sugimoto, Francis Dupont, Masahide Nakamura, 15-Dec-07, This document describes the need for an interface between Mobile IPv6 and IPsec/IKE and show how the two protocols can interwork. We propose a set of extensions to the PF_KEY framework which allows smooth and solid operation of IKE in a Mobile IPv6 environment. The first extension is called PF_KEY MIGRATE and is for migrating the endpoint addresses of a IPsec Security Association pair in tunnel mode. The second extension is named SADB_X_EXT_PACKET and allows IKE to make the right choice for address selection in bootstrapping process. Both extensions are helpful for assuring smooth interworking between Mobile IPv6 and IPsec/IKE and achieving performance optimization. "EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)", Paul Funk, Simon Blake-Wilson, 11-Mar-08, EAP-TTLS is an EAP method that provides additional functionality beyond what is available in EAP-TLS [RFC2716bis]. In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP- TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely-deployed authentication mechanisms. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle and other attacks. EAP-TTLS also allows client and server to establish keying material for use in the data connection between the client and access point. The keying material is established implicitly between client and server based on the TLS handshake. This document describes EAP-TTLSv0; that is, the original version 0 of the EAP-TTLS protocol, which has been widely deployed. "Requirements for Firewall Configuration Protocol", Gabor Bajko, 11-Oct-07, 3GPP2 is working in specifying a way to allow the mobile network subscribers to configure the Firewalls in their network according to their needs[3]. This document defines requirements for a Firewall Configuration Protocol. It has been produced by a number of 3GPP2 member companies and endorsed by 3GPP2. It contains 3GPP2 requirements to a next generation Firewall Configuration Protocol. With the number of threats that keep increasing on the Internet, many networks have decided to deploy Firewalls to reduce the possible risks and protect their users as well as their network resources. Firewalls can however present many issues with new protocols, applications and scenarios to be supported. Data packets may be discarded at the Firewalls. In addition, the clients may often be the only parties that know the requirements and details of the data communications. This document therefore explains why a protocol allowing clients to configure Firewalls would be useful, and attempts to identify the requirements and features to be supported by such a protocol. "BGP Point to Multipoint LSP", Satoru Matsushima, Tetsuya Murakami, Kenichi Nagami, 25-Feb-08, This document describes motivations and use cases to P2MP extension of BGP. This extension will allow to make both Inter-AS and Intra-AS P2MP LSP that fit to some use cases then also clarify required features. "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). "IS-IS BFD Enabled TLV", Christian Hopps, Les Ginsberg, 19-Nov-07, This document describes a TLV for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection protocol (BFD). There exist certain scenarios in which IS-IS will not react appropriately to a BFD detected forwarding plane failure without use of either this TLV or some other method. "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, 19-Mar-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. "IANA Considerations for XCAST (Explicit Multi-Unicast)", Chih-Chang Hsu, 4-Apr-05, XCAST (Explicit Multi-Unicast) is an experimental protocol for small group multicasting. This protocol requires IANA allocations for a new type of multicast address, a routing type of IPv6 routing header, an option type of Destination Option header and an option header of IPv6 Hop-by-Hop Options header. This document contains guidelines to IANA about what allocations are required for XCAST protocol. "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. "SCTP NAT Traversal Considerations", Qiaobing Xie, Randall Stewart, Matt Holdrege, Michael Tuexen, 17-Nov-07, This document defines and classifies scenarios for the usage of SCTP in networks with NATs and similar middleboxes. "An Extensible Format for Email Feedback Reports", Yakov Shafranovich, 12-Mar-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. "Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, 17-Nov-07, 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 the NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NAT's so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point traversal scenario described in [I-D.xie-behave-sctp-nat-cons]. Furthermore both algorithms are compared. "Strengthening Digital Signatures via Randomized Hashing", Shai Halevi, Hugo Krawczyk, 23-Oct-07, This document describes a randomized hashing scheme consisting of a simple message randomization transform that when used as a front-end to regular hash-then-sign signature schemes, such as RSA and DSS, frees these signatures from their current vulnerability to off-line collision attacks against the underlying hash function. The proposed mechanism can work with any hash function as-is and requires no change to the underlying signature algorithm. Incorporating this mechanism into existing applications requires changes that are comparable in their complexity to accommodating a new (deterministic) hash function such as SHA-256. Visit http://www.ee.technion.ac.il/~hugo/rhash/ for more information and updates on this work. "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, Lisa Dusseault, 18-Nov-07, This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of exchanging and processing scheduling messages based on the iCalendar Transport- Independent Interoperability Protocol (iTIP). This document defines the "calendar-schedule" feature of CalDAV. "Bundle Security Protocol Specification", Susan Symington, Stephen Farrell, Howard Weiss, Peter Lovell, 24-Feb-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, 15-Nov-07, 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, 16-Nov-07, This draft describes the applicability of loop free convergence technologies to a number of network applications. "H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths", Doug Leith, 7-Apr-08, This document describes a number of changes to the TCP congestion control algorithm to to improve performance in high bandwidth-delay product paths. We focus on changes to the congestion avoidance mode, rather than slow-start. "Security Extension for Unidirectional Lightweight Encapsulation Protocol", Haitham Cruickshank, Prashant Pillai, Sunil Iyengar, 17-Oct-07, 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, 9-Jan-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, 9-Apr-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, 20-Feb-08, This document proposes the use of the Reason header field in SIP responses. "Synchronisation of Loop Free Timer Values", Alia K, Stewart Bryant, 14-Feb-08, This draft describes a mechanism that enables routers to agree on a common convergence delay time for use in loop-free convergence. "Simple Mail Transfer Protocol", John Klensin, 20-Mar-08, This document is a specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" mail reading systems and mobile environments. "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. "IPv6 Address Assignment to End Sites", Thomas Narten, 11-Mar-08, RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document revisits and updates the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is a policy issue under the purview of the RIRs, subject to IPv6 architectural andoperational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original 3177 recommendations. The document clarifies that changing the /48 recommendation is one of policy, and has minimal impact on the IPv6 architecture and on IETF Standards. "Dynamic Provisioning using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", Nancy Cam-Winget, David McGrew, Joseph Salowey, Hao Zhou, 7-Apr-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. "Sieve Email Filtering: Date and Index Extensions", Ned Freed, 15-Mar-08, This document describes the "date" and "index" extensions to the Sieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. Change History (to be removed prior to publication as an RFC) Changed usage from Julian Days to Modified Julian Days. This has the advantage that the number are smaller and day numbers change at midnight rather than at noon. Added the ability to return the day of the week. Use the term "argument" instead of "parameter" throughout. Added a "std11" part type as a means to operate on values formatted in the same way as a Date: header field. Changed the terminology from "part" to "date-part". Updated reference to 3028bis, corrected miscellaneous typos. Updated the IANA registration templates. Added "time" and "date" as possible date-part values with appropriate syntax. Restricted allowed ISO 8601 formats so that comparisons will be reliable. Changed the date-part "timezone" to "zone" to make it consistent with the :zone parameter. Removed the reference to structured header fields in the description of the date test. Added a paragraph to make it clear that :index counts header fields, not the contents of header fields. Allow leap seconds. Added :originalzone parameter to date test. Added several examples. Made the specification of :last without :index an error, aligning this specification with editheader. Added some security considerations text about the impact of currentdate on script analysis. Updated references to recently published RFCs. "Secure SCTP", Carsten Hohendorf, 9-Jan-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. "Survey of IP address autoconfiguration mechanisms for MANETs", Carlos Bernardos, Maria Calderon, Hassnaa Moustafa, 8-Apr-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. "The Core Session Initiation Protocol User Agent Protocol Data Set", Sumanth Channabasappa, Sam Ganesan, 18-Nov-07, This document defines the properties and format for the core SIP user agent protocol dataset. The properties defined in this document are expected to be common to most SIP user agents regardless of whether the user agent support audio, video, text or any combination of media. These core SIP properties are considered to be a dataset. Several datasets may be combined into documents or profiles that are provided to SIP user agents so that they can operate with the desired behavior. "Cisco Systems UniDirectional Link Detection (UDLD) Protocol", Marco Foschiano, 9-Apr-07, This document describes a Cisco Systems protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused for instance by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms. This document explains the protocol objectives and applications, illustrates the specific premises the protocol was based upon and describes the protocol architecture and related deployment issues, to serve as a possible base for future standardization. "An IPFIX-Based File Format", Brian Trammell, 8-Nov-07, This document describes a file format for the storage of flow data based upon the IPFIX message format. It proposes a set of requirements for flat-file, binary flow data file formats, then applies the IPFIX message format to these requirements to build a new file format. This IPFIX-based file format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. "Operational Reliability for EDIINT AS2 draft-duker-as2-reliability-03.txt", John Duker, Dale Moberg, 12-Feb-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, 19-Mar-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, 14-Jan-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. "Tools for the Evaluation of Simulation and Testbed Scenarios", Sally Floyd, Eddie Kohler, Intellectual Property, 23-Feb-08, This document describes tools for the evaluation of simulation and testbed scenarios used in research on Internet congestion control mechanisms. We believe that research in congestion control mechanisms has been seriously hampered by the lack of good models underpinning analysis, simulation, and testbed experiments, and that tools for the evaluation of simulation and testbed scenarios can help in the construction of better scenarios, based on better underlying models. One use of the tools described in this document is in comparing key characteristics of test scenarios with known characteristics from the diverse and ever-changing real world. Tools characterizing the aggregate traffic on a link include the distribution of per-packet round-trip times, the distribution of connection sizes, and the like. Tools characterizing end-to-end paths include drop rates as a function of packet size and of burst size, the synchronization ratio between two end-to-end TCP flows, and the like. For each characteristic, we describe what aspects of the scenario determine this characteristic, how the characteristic can affect the results of simulations and experiments for the evaluation of congestion control mechanisms, and what is known about this characteristic in the real world. We also explain why the use of such tools can add considerable power to our understanding and evaluation of simulation and testbed scenarios. "Delay-Tolerant Networking Security Overview", Stephen Farrell, Susan Symington, Howard Weiss, Peter Lovell, 24-Feb-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. "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", Martin Stiemerling, 7-Mar-07, The Host Identity Protocol (HIP) changes the way in which two Internet hosts communicate. One key advantage over other schemes is that HIP does not require modifications to the traditional network- layer functionality of the Internet, i.e., its routers. In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet. These "middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts. Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication and others can render HIP communication impossible. This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls. It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes. This document is a product of the IRTF HIP Research Group. "MTLS: TLS Multiplexing", Mohamad Badra, Ibrahim Hajjeh, 25-Oct-07, The Transport Layer Security (TLS) standard provides connection security with mutual authentication, data confidentiality and integrity, key generation and distribution, and security parameters negotiation. However, missing from the protocol is a way to multiplex application data over a single TLS session. This document defines MTLS, a new TLS sub-protocol running over TLS (or DTLS) Record protocol. The MTLS design provides application multiplexing over a single TLS (or DTLS) session. Therefore, instead of associating a TLS connection with each application, MTLS allows several applications to protect their exchanges over a single TLS session. "Four-octet AS Specific BGP Extended Community", Yakov Rekhter, 8-Apr-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. "Password-Authenticated Diffie-Hellman Exchange (PAK)", Alec Brusilovsky, 19-Nov-07, 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. "vCard Extensions to WebDAV (CardDAV)", Cyrus Daboo, 23-Feb-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 . "The Session Initiation Protocol User Agent Identity Profile Data Set", Daniel Petrie, Sumanth Channabasappa, Sam Ganesan, 18-Nov-07, This document defines the properties and data format for the SIP user agent identity profile data set. The properties in this data set define identities or SIP address of records (AORs) related to incoming or outgoing SIP signaling on a user agent. The identities may be those that are registered via the SIP REGISTER method or identities which are provisioned on the user agent. These identities may be used or referenced when defining identity specific handling related to SIP features on the user agent. "The Session Initiation Protocol User Agent VoIP Features Data Set", Daniel Petrie, Sumanth Channabasappa, Sam Ganesan, 18-Nov-07, This document defines the properties and format for the SIP user agent VoIP Features data set. The properties defined in this document are expected to be common to most SIP user agents that provide VoIP capabilities. These VoIP Feature properties are considered to be a data set. Several types of datasets may be combined into documents that are provided to SIP user agents so that they can operate with the desired behavior. "UDP Encapsulation of SCTP Packets", Michael Tuexen, Randall Stewart, 17-Nov-07, This document describes a simple method of encapsulating SCTP Packets. This makes it possible to use SCTP in networks with legacy NAT not supporting SCTP. "Privacy Aspects Terminology", Wassim Haddad, Erik Nordmark, 28-Oct-07, 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. "Address Resolution for GMPLS controlled PSC Ethernet Interfaces", Zafar Ali, Hassan Sheikh, Tomohiro Otani, Hidetsugu Sugiyama, 27-Feb-08, This document outlines some interoperability issues observed with the use of ARP over GMPLS controlled Ethernet router-to- router (PSC) interfaces transiting from a non-Ethernet core, e.g., FSC or LSC core. The document also recommends some procedures to address these issues. The aim of this document is to facilitate and ensure better interworking of GMPLS- capable Label Switching Routers (LSRs), based on experience gained in interoperability testing. "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob Briscoe, Arnaud Jacquet, T Moncaster, Alan Smith, 10-Jan-08, This document introduces a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. The protocol arranges an extended ECN field in each packet so that, as it crosses any interface in an internetwork, it will carry a truthful prediction of congestion on the remainder of its path. Then the upstream party at any trust boundary in the internetwork can be held responsible for the congestion they cause, or allow to be caused. So, networks can introduce straightforward accountability and policing mechanisms for incoming traffic from end-customers or from neighbouring network domains. The purpose of this document is to specify the re-ECN protocol at the IP layer and to give guidelines on any consequent changes required to transport protocols. It includes the changes required to TCP both as an example and as a specification. It also gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion. And it describes example mechanisms that ensure the dominant selfish strategy of both network domains and end-points will be to set the extended ECN field honestly. Authors' Statement: Status (to be removed by the RFC Editor) Although the re-ECN protocol is intended to make a simple but far- reaching change to the Internet architecture, the most immediate priority for the authors is to delay any move of the ECN nonce to Proposed Standard status. The argument for this position is developed in Appendix I. Changes from previous drafts (to be removed by the RFC Editor) Full diffs created using the rfcdiff tool are available at From -04 to -05 (current version): Completed justification for packet marking with FNE during slow- start(Appendix D). Minor editorial changes throughout. From -03 to -04: Clarified reasons for holding back ECN nonce (Section 3.2 & Appendix I). Clarified Figure 1. Added Section 4.1.1.1 on equivalence of drops and ECN marks. Improved precision of Section 5.6 on IP in IP tunnels. Explained the RTT fairness is possible to enforce, but unlikely to be required (Section 6.1.3 & Appendix F). Explained that bulk per-user policing should be adequate but per- flow policing is also possible if desired, though it is not likely to be necessary (Section 6.1.5 & Appendix G). Reinforced need for passive policing at inter-domain borders to enable all-optical networking (Section 6.1.6). Minor editorial changes throughout. From -02 to -03: Started guidelines for re-ECN support in DCCP and SCTP. Added annex on limitations of nonce mechanism. Minor editorial changes throughout. From -01 to -02: Explanation on informal terminology in Section 3.4 clarified. IPv6 wire protocol encoding added (Section 5.2). Text on (non-)issues with tunnels, encryption and link layer congestion notification added (Section 5.6 & Section 5.7). Section added giving evolvability arguments against encouraging bottleneck policing (Section 6.1.2). And text on re-ECN's evolvability by design added to Section 6.1.3 Text on inter-domain policing (Section 6.1.6) and inter-domain fail-safes (Section 6.1.7) added. From -00 to -01: Encoding of re-ECN wire protocol changed for reasons given in Appendix B and consequently draft substantially re-written. Substantial text added in sections on applications, incremental deployment, architectural rationale and security considerations. "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. "DNS Glue RR Survey and Terminology Clarification", Peter Koch, 19-Nov-07, This document presents a survey of the use of the term "glue record" in DNS related RFCs and proposes a terminology for the various glue policies seen in different TLDs. "Issues Discussed in Revising BGP-4", Andrew Lange, 13-Dec-07, This document records the issues discussed and the consensus reached in the Interdoming Routing (IDR) Working Group during its efforts to revise and bring up to date the base specification for the BGP-4 protocol. "IAX: Inter-Asterisk eXchange Version 2", Mark Spencer, Brian Capouch, Ed Guy, Frank Miller, Kenneth Shumard, 30-Mar-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. "IPv6 over Low Power WPAN Security Analysis", Soohong Daniel Park, 25-Feb-08, This document discusses possible threats and security options for IPv6-over-IEEE802.15.4 networks. It is an informational document to raise awareness of security issues in IPv6 lowPan networks. "Atom Syndication Format Tombstones", James Snell, 4-Jan-08, This specification adds mechanisms to the Atom Syndication Format which Atom Feed publishers can use to explicitly indicate that specific Atom entries have been removed from an Atom feed. "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 to Identify the Receiving Interface", Alia Atlas, Ronald Bonica, Nuova Systems, Naiming Shen, Enke Chen, 16-Nov-07, This memo defines ICMP extensions, using ICMP multi-part messages, through which a router or host can explicitly identify the interface upon which an undeliverable datagram anrrived. The incoming interface can be identified by ifIndex, name, and/or address, as already used in MIBs and by OSPF. The extensions defined herein are particularly useful when troubleshooting networks with unnumbered interfaces, parallel interfaces and/or asymmetric routing. "OCRA: OATH Challenge-Response Algorithms", Salah Machani, Intellectual Property, 3-Apr-08, This document describes the OATH algorithm for challenge-response authentication and signatures. This algorithm is based on the HOTP algorithm [RFC4226] that was introduced by OATH (initiative for Open AuTHentication) [OATH] and submitted as an individual draft to the IETF in 2006. OATH-HOTP-VARIANTS Expires - October 2008 [page 1] OCRA: OATH Challenge Response Algorithms April 2008 "A Basic Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework", Chris Boulton, Tim Melanchuk, Scott McGlashan, 24-Feb-08, This document defines a Media Control Channel Framework Package for basic Interactive Voice Response (IVR) interaction. "Centralized Conferencing Manipulation Protocol", Mary Barnes, Chris Boulton, Henning Schulzrinne, 25-Feb-08, The Centralized Conferencing Manipulation Protocol (CCMP) defined in this document provides the mechanisms to create, change and delete objects related to centralized conferences, including participants, their media and their roles. The protocol relies on web services and SIP event notification as its infrastructure, but can control conferences that use any signaling protocol to invite users. CCMP is based on the Simple Object Access Protocol (SOAP), with the data necessary for the interactions specified via Web Services Description Language (WSDL). "Issues with existing Cryptographic Protection Methods for Routing Protocols", Vishwas Manral, 11-Feb-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. "The "pack" URI Scheme", Andrey Shur, Jerry Dunietz, 10-Mar-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. "Requirements for supporting Customer RSVP and RSVP-TE Over a BGP/MPLS IP-VPN", Kenji Kumaki, 20-Feb-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 "LowPan Neighbor Discovery Extensions", Samita Chakrabarti, Erik Nordmark, 20-Nov-07, IETF 6LowPan working group defines IPv6 over low-power personal area network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have multicast support, although it supports broadcast. Due to the nature of LowPan network or sensor networks, broadcast messages should be minimized. This document suggests some optimizations to IPv6 Neighbor Discovery related multicast messages in order to reduce signaling in the low-cost low-powered network. "The Jabber-ID Header Field", Peter Saint-Andre, 4-Dec-07, This document defines a header field that enables the author of an email or netnews message to include a Jabber Identifier in the message header block for the purpose of associating the author with a particular Extensible Messaging and Presence Protocol (XMPP) address. "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. "Using DNS SRV to Specify a Global File Name Space with NFS version 4", Craig Everhart, William Adamson, Jiaying Zhang, 12-Nov-07, 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. "Automated key selection extension for the TCP Enhanced Authentication Option", Brian Weis, Chandrashekhar Appanna, David McGrew, Anantha Ramaiah, 19-Oct-07, This memo describes an automated key selection extension for the TCP [RFC0793] authentication option [I-D.bonica-tcp-auth]. This key selection extension allows two TCP endpoints to authenticate TCP segments using a Message Authentication Code (MAC) key chosen dynamically by an endpoint, rather than using a pre-configured MAC key. "WiMAX Forum/3GPP2 Proxy Mobile IPv4", Kent Leung, 1-Apr-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, and the existing application of PMIPv4 in WiMAX Forum and 3GPP2. "Media Server Markup Language (MSML)", Adnan Saleem, 12-Feb-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 Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)", Seisho Yasukawa, Adrian Farrel, 14-Nov-07, 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). Since P2MP TE LSP routes are sometimes complex to compute, and given the use of PCE in MPLS networks it is likely that PCE will be used in P2MP MPLS-TE networks. 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 traffic engineering. "PCC-PCE Communication Requirements for VPNs", Seisho Yasukawa, Adrian Farrel, 14-Feb-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. "Extended Shim6 Design for ID/loc split and Traffic Engineering", Erik Nordmark, 23-Feb-08, The Shim6 protocol provides for locator agility while satisfying the 'first, do no harm' security requirements. This document outlines three rather orthogonal sets of extensions to Shim6. The first one is how to procide complete separation between identifiers and locators. The second one is how to allow routers to rewrite the locators in the shim6 packets as a way to provide traffic engineering information to the hosts. The third one is the outline of a simple extension to allow shim6, with a CGA upper-layer ID, to operate using IPv4 addresses as locators. The purpose of this outline is to stimulate discussions. "Supporting Multipoint-to-Point Label Switched Paths in Multiprotocol Label Switching Traffic Engineering", Seisho Yasukawa, Adrian Farrel, 14-Feb-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, 25-Feb-08, Mobile IPv6 [10] enables mobile nodes to remain reachable while roaming on the Internet. With its current specification, the location of a mobile node can be revealed and its movement can be tracked by simply monitoring its IP packets. In this document, we consider the MIP6 location privacy problem described in [14] and propose efficient and secure techniques to protect the location privacy of a mobile node. "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. "GIST Extension for Hybrid On-path Off-path Signaling (HyPath)", Luís Cordeiro, Marilia Curado, Edmundo Monteiro, Vitor Bernardo, David Palma, Florin Racaru, Michel Diaz, Christophe Chassot, 23-Feb-08, In a multi-domain Internet that offers QoS guaranties for applications, there is the need of signaling among the domain entities that are responsible for the management of QoS. Because different domains have different network protocols and topologies, the HyPath approach uses the NSIS protocol and interactions with the local routing protocols to have an off-path signaling in hybrid environments. "Datagram Transport Layer Security for Stream Control Transmission Protocol", Michael Tuexen, Eric Rescorla, 17-Nov-07, 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. "Enhanced validation of domains for HTTP State Management Cookies using DNS", Yngve Pettersen, 24-Feb-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, 24-Feb-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. "Flow Bindings in Mobile IPv6 and Nemo Basic Support", Hesham Soliman, Nicolas Montavont, Niko Fikouras, Koojana Kuladinithi, 19-Nov-07, This document introduces extensions to Mobile IPv6 [1] and Nemo Basic Support [2] that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to take full advantage of the different properties associated with each of their interfaces. "An MP-BGP protocol extension to advertize TE-related PE-CE link information", JP Vasseur, Gargi Nalawade, Kenji Kumaki, 18-Nov-07, This document proposes MP-BGP protocol extension so as to convey Traffic Engineering Link characterictics of PE (Provider Edge) - CE (Customer Edge) links in order to extend the visibility of the Traffic Engineering Database to those links. This can then be used to more efficiently compute CE-to-CE Traffic Engineering Label Swtiched Path (TE LSP) when required to provide specific services such as bandwidth guarantees and end to end fast protection in a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) environment. "ZRTP: Media Path Key Agreement for Secure RTP", Philip Zimmermann, Alan Johnston, Jon Callas, 10-Mar-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 a secret is available from the signaling protocol, authentication. ZRTP can utilize two Session Description Protocol (SDP) attributes to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP profiles. "OSPF MPR Extension for Ad Hoc Networks", Emmanuel Baccelli, 12-Oct-07, This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, enhanced with MANET techniques based on multi-point relaying (MPR). "Session Description Protocol (SDP) Indicators for Datagram Transport Layer Security (DTLS)", Jason Fischl, Hannes Tschofenig, 18-Nov-07, This specification defines how to use the Session Description Protocol (SDP) to signal that media will be transported over Datagram Transport Layer Security (DTLS) or where the SRTP security context is established using DTLS and. It reuses the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate which will be presented during the DTLS handshake. "DNSSEC Validator API", Abhijit Hayatnagarkar, Suresh Krishnaswamy, 4-Jan-08, The DNS Security Extensions (DNSSEC) provide origin authentication and integrity of DNS data. However, the current resolver Application Programming Interface (API) does not allow a security-aware resolver to communicate detailed results of DNSSEC processing back to the application. This document describes an API between applications and a validating security-aware stub resolver that allows applications to control the validation process and obtain results of DNSSEC processing. "Firewall friendly Return-Routability Test (RRT) for Mobile IPv6", Gabor Bajko, 25-Feb-08, This document defines a slightly modified Return Routability Test (RRT) for MIPv6 [RFC3775]. The herein defined RRT mechanism is intended for CoA exchanges between the MN and the CN. Once the MN and CN find out their peers' valid addresses, an additional mechanism, defined in [I-D.tschofenig-mip6-ice], will be used to run connectivity checks to figure out which of the address pairs have connectivity and, if needed, open the required pinholes in the firewalls as described in [4]. The defined mechanism is intended to work with current firewalls without requiring any support from them. "Internet Key Exchange Protocol: IKEv2", Charlie Kaufman, Paul Hoffman, Pasi Eronen, 25-Feb-08, This document describes version 2 of the Internet Key Exchange (IKE) protocol. It is a restatement of RFC 4306, and includes all of the clarifications from RFC 4718. "Media Playback Control Protocol Requirements", Steven Whitehead, Marie-Jose Montpetit, Xavier Marjou, Sam Ganesan, 22-Feb-08, The media playback control functionality controls the delivery of streaming media by the means of commands like pause, fast forward, fast rewind, slow forward, slow rewind. This document presents some of the requirements for a media control protocol that does not contain any session setup semantics in it. "A Conference Control Package for the Media Control Channel Framework", Chris Boulton, Tim Melanchuk, Scott McGlashan, Asher Shiratzky, 24-Feb-08, This document defines a Conference Control Package for the Media Control Channel Framework. This Control Package aims to fulfill Conferencing requirements using the SIP Control Framework. "A VoiceXML Control Package for the Media Control Channel Framework", Chris Boulton, Tim Melanchuk, Scott McGlashan, 24-Feb-08, This document defines a VoiceXML Control Package for the Media Control Channel Framework. This Control Package extends the Basic IVR control package with support for VoiceXML dialogs. "Optimizations to Secure Connectivity and Mobility", Meghana Sahasrabudhe, Vijay Devarapalli, 19-Feb-08, Users that need to connect to their enterprise network from an untrusted network require secure connectivity and mobility. Enterprise users are increasingly using mobile nodes. A user may need to connect to the enterprise network from anywhere, and in a number of scenarios, from untrusted networks. There are existing specifications developed by the Mobile IPv4 working group that describe solutions for enterprise secure connectivity and mobility. This document proposes optimizations to those solutions to reduce the tunneling overhead and allow for a number of new access modes. "Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility", Thomas Dreibholz, Jobin Pulinthanath, 9-Jan-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, 9-Jan-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, 3-Dec-07, 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. The BMWG produces two major classes of documents: Benchmarking "Telnet START-TLS Option", Jeffrey Altman, 15-Dec-06, Telnet service has long been a standard Internet protocol. However, a standard way of ensuring privacy and integrity of Telnet sessions has been lacking. This document proposes a standard method for Telnet servers and clients to use the Transport Layer Security (TLS) protocol. It describes how two Telnet participants can decide whether or not to attempt TLS negotiation, and how the two participants should process authentication credentials exchanged as a part of TLS startup. "Telnet Authentication Option", Jeffrey Altman, 15-Dec-06, This document describes the authentication option to the Telnet protocol, RFC 854, as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. While this document summarizes currently utilized commands and types it does not define a specific authentication type. Separate documents are to be published defining each authentication type. This document updates a previous specification of the Telnet authentication option, RFC 2941, to allow the AUTHENTICATION option to be used in conjunction with the START_TLS option, RFC XXXX. "Telnet Authentication: Kerberos Version 5", Jeffrey Altman, 15-Dec-06, This document describes how Kerberos Version 5 [RFC 4120] is used with the Telnet protocol [RFC 854]. It describes an Telnet Authentication suboption to be used with the Telnet Authentication option [RFC YYYY]. This mechanism can also used to provide keying material to provide data confidentiality services in conjunction with the Telnet Encryption option [RFC 2946]. This document updates a previous specification of the Telnet Authentication Kerberos 5 method, RFC 2942 [4], to allow Kerberos 5 Telnet authentication to be used in conjunction with the START_TLS option [RFC XXXX]. "Telnet Authentication: SRP", Jeffrey Altman, 18-Dec-06, This document specifies an authentication scheme for the Telnet protocol [RFC 854] under the framework described in [RFC YYYY], using the Secure Remote Password Protocol (SRP) authentication mechanism. The specific mechanism, SRP-SHA1, is described in [RFC2945]. This document updates a previous specification of the Telnet Authentication SRP method, RFC 2944, to allow SRP Telnet authentication to be used in conjunction with the Telnet START_TLS option [RFC YYYY]. "Experiences from Using Unicast RPF", Pekka Savola, 23-Jan-08, RFC 3704 (BCP 84) published in March 2004 provided an ingress filtering technique update to RFC 2827 (BCP 38). This memo tries to document operational experiences learned practising ingress filtering techniques, in particular ingress filtering for multihomed networks. "SNMP Traffic Measurements and Trace Exchange Formats", , 17-Mar-08, The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are. This document proposes to carry out large scale SNMP traffic measurements in order to develop a better understanding how SNMP is used in real world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study. This document was produced within the IRTF's Network Management Research Group (NMRG) and represents the consensus of all of the active contributors to this group. "Requirements for Web Authentication Resistant to Phishing", Sam Hartman, 18-Nov-07, This memo proposes requirements for protocols between web identity providers and users and for requirements for protocols between identity providers and relying parties. 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 perform mutual authentication 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. "TCP Response to Lower-Layer Connectivity-Change Indications", Simon Schuetz, Nikolaos Koutsianas, Lars Eggert, Wesley Eddy, Yogesh Swami, Khiem Le, 22-Feb-08, When the path characteristics between two hosts change abruptly, TCP can experience significant delays before resuming transmission in an efficient manner or TCP can behave unfairly to competing traffic. This document describes TCP extensions that improve transmission behavior in response to advisory, lower-layer connectivity-change indications. The proposed TCP extensions modify the local behavior of TCP and introduce a new TCP option to signal locally received connectivity-change indications to remote peers. Performance gains result from a more efficient transmission behavior and there is no difference in aggressiveness in comparison to a newly-started connection. "Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices", Scott Poretsky, Vijay Gurbani, Carol Davids, 18-Nov-07, 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 intedned for use in a companion Methodology document for complete performance characterization of a device in a variety of network 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, 7-Feb-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 for the contents of Resource Certificate Repositories and the proposed internal structure of a Repository Cache that is intended to facilitate synchronization across a distributed collection of repositories and facilitate certificate path construction. "The MANET Virtual Ethernet (VET) Abstraction", Fred Templin, Steven Russert, Seung Yi, 4-Apr-08, Mobile Ad-hoc Networks (MANETs) connect routers on links with asymmetric reachability characteristics, and may also connect to other networks including the Internet. Routers in MANETs must have a way to automatically provision IP addresses/prefixes and other information. This document specifies a Virtual Ethernet (VET) abstraction for autoconfiguration and operation of routers in MANETs. "The Additional Modes of Operation for Camellia and Its Use With IPsec", Akihiro Kato, Masayuki Kanda, 19-Mar-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 IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity. "Admission Control enabled On demand Routing (ACOR)", Kettaf Noureddine, 12-Oct-07, The Admission Control enabled On-demand Routing (ACOR) protocol is intended for use by MANETs. It is a reactive routing protocol designed to support quality of service (QoS) on the end to end route. ACOR is based on simple local cost functions at each node, and global cost function to represent the end-to-end cost of a route, in addition to a simple admission control mechanism for implicit resource reservation adapted to frequent changing of network topology. "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) co-operation with HTTP Extensions for Distributed Authoring (WEBDAV)", Jari Urpalainen, 16-Nov-07, The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) allows a client to read, write and modify application configuration data, stored in XML format on an HTTP server. HTTP Extensions for Distributed Authoring (WebDAV) provides many useful HTTP extensions for web content authoring. This document describes conventions for the co-operation of XCAP resources with WebDAV. "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. "Templates for Internet Drafts Containing MIB Modules", David Harrington, 10-Apr-08, This memo references three annotated templates for IETF documents that contain the definition of MIB modules. It is intended to reduce the work of the editors of such documents, making these documents more uniform and easier to read and review, thus furthering the quality of such documents and expediting their publication. "Using the Protected One-Time Password Protocol for EAP-FAST Provisioning", David Mitton, Nancy Cam-Winget, 25-Feb-08, EAP-FAST is an extensible EAP method that enables the provisioning of credentials or other information by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. As the tunnel may be unauthenticated, EAP-FAST further enables the use of inner EAP methods to establish mutual authentication prior to provisioning. This document describes how EAP-POTP may be used as the EAP-FAST inner method for credential provisioning. "HTTP Header Linking", Mark Nottingham, 17-Mar-08, This document clarifies the status of the Link HTTP header and attempts to consolidate link relations in a single registry. "Diameter Base Protocol MIB", Glen Zorn, Subash Comerica, 10-Feb-08, Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter protocol is designed to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter protocol. "Diameter Credit Control Application MIB", Glen Zorn, Subash Comerica, 10-Feb-08, Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter base protocol is intended to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter Credit Control application. "Domain Name System (DNS) Cookies", Donald Eastlake 3rd, 25-Feb-08, DNS cookies are a light-weight DNS transaction security mechanism designed for incremental deployment. They provide limited protection to DNS servers and resolvers against a variety of increasingly common denial-of-service and cache poisoning or forgery attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT, and Anycast. "Internet Message Format", Pete Resnick, 7-Feb-08, This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. "Configuration Data Model for IPFIX and PSAMP", Gerhard Muenz, Benoit Claise, 20-Feb-08, This document specifies a data model for the configuration of metering processes, exporting processes, and collecting processes for 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 as a YANG module to ensure compatibility with the Netconf protocol. A YANG-to-XSD converter is available which allows generating an XML Schema Definition of the data model. "Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture", Flemming Andreasen, Bernie McKibben, Bill Marshall, 21-Feb-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. "Considerations for Information Services and Operator Services Using SIP", John Haluska, Renee Berkowitz, Paul Roder, Wesley Downum, Richard Ahern, Paul Lung, Nicholas Costantino, Chris Blackwell, Jim Mellinger, 18-Nov-07, Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to reproduce the current PSTN behaviour. "Certificate Authentication in SIP", Steve Dotson, 6-Nov-07, This document defines requirements for adding certificate authentication to the Session Initiation Protocol (SIP). The use case addressed is that of a SIP device authenticating on behalf of configured users using a device certificate for purposes such as registration. This document is being presented with the intention of providing requirements to any potential solutions specifying certificate authentication within SIP networks. Supporting certificate authentication in SIP would provide strong authentication and increase the types of possible deployment scenarios. "VCCV Extensions for Segmented Pseudo-Wire", Neil Hart, 19-Nov-07, This document describes extensions to Single Hop Virtual Circuit Connectivity Verification (SH-VCCV) procedures for segmented pseudo wires to test the end-to-end forwarding datapath and to provide a MS- PW segment trace capability. This is accomplished by changing the adaptation function for the Single Hop VCCV parameter at the switching point between two distinct PW control planes. "OSPF Database Exchange Summary List Optimization", Richard Ogier, 16-Dec-07, This document describes a backward compatible optimization for the Database Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list an LSA in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reduces Database Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets. "Data Channel Status Confirmation Extensions for the Link Management Protocol", Dan Li, Huiying Xu, Fatai Zhang, Snigdho Bardalai, Julien Meuric, Diego Caviglia, 21-Feb-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 Li Expires August 2008 [page 1] draft-li-ccamp-confirm-data-channel-status-03.txt February 2008 data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. "DMMP: Dynamic Mesh-based Overlay Multicast Protocol", Jun Lei, Xiaoming Fu, Dieter Hogrefe, 20-Feb-08, This document describes a Dynamic Mesh-based overlay Multicast Protocol (DMMP) framework to support multicast data delivery applications without relying on classic IP multicast, including multicast group management, overlay hierarchy establishment, multicast tree construction and data forwarding scheme from a source to a number of receivers. The DMMP framework builds on control plane functions which dynamically manage an overlay core and a multicast tree. The key idea is a number of end hosts self-organize into an overlay mesh, and dynamically maintain such a mesh. Based on the constructed mesh, some core-based clusters are formed with capacity- aware trees inside. Then, a multicast tree consisting of DMMP-aware end hosts (and/or specific routers) is built on the top of the overlay core for the efficient delivery of the multicast data. "Reporting Metrics: Different Points of View", Al Morton, Gomathi Ramachandran, Ganga Maguluri, 18-Nov-07, Consumers of IP network performance metrics have many different uses in mind. This memo categorizes the different audience points of view. It describes how the categories affect the selection of metric parameters and options when seeking info that serves their needs. The memo then proceeds to discuss "long-term" reporting considerations (e.g, days, weeks or months, as opposed to 10 seconds). "Identifying and Reacting to Unsolicited DNS Queries", Peter Koch, 19-Nov-07, This document deals with unsolicited Domain Name System (DNS) queries directed towards authoritative name servers. It identifies reasons for the existence of these queries and lists some observed or proposed reactions. "Canonical Textual Representation of Four-octet AS Numbers", Geoff Huston, George Michaelson, 3-Dec-07, A taxonomy of textual representations for four-octet Autonomous System (AS) numbers is defined. The 'asdot' textual representation is recommended. The syntax chosen avoids ambiguity with Border Gateway Protocol (BGP) community string representation of AS numbers. It is recommended that this textual representation be used by all documents, systems and user interfaces referring to four-octet AS numbers. "LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS", Pranjal Dutta, 24-Feb-08, [RFC4762] describes a mechanism to remove or unlearn MAC addresses which have been dynamically learned in a VPLS Instance for faster convergence on topology change. The procedure also removes the MAC addresses in the VPLS which does not require relearning due to such topology change. This document defines an extension to MAC Address Withdrawal procedure with empty MAC List [RFC4762], that enables a Provider Edge(PE) device to remove only the MAC addresses that needs to be relearned. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Authentication and Path-Provision to Traverse the VPN Gateway in Mobile IPv4", Miyoung Kim, 13-Nov-07, Isolating the access to mobility agents by the VPN gateway which guards the home agent, home resources is disturbing the operations of mobile node away from its home that needed to perform the registration of the current location according to the specification because the access from the outside is restricted by the VPN policy. This paper presents the authentication and key exchange scheme using the AAA infrastructure for a user in Internet to access the Intranet behind the VPN gateway. By defining the role of authentication and tunnel processing for each agent or relaying entity, we are able to obtain our goal to the security-aware environment. Also, the performance result of the proposed scheme is discussed in depth. "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. "An Enhanced Mobile IPv6 Handover for Roaming between Administrative Domains Based on AAA", Youngsong Mun, 1-Nov-07, When Mobile IPv6 (MIPv6) is deployed in commercial network, a mobile node needs AAA services for authentication, authorization and accounting. MIPv6, however, does not provide any mean to authenticate mobile nodes that are roaming in different domains, although visited networks will need to check whether access of mobile nodes should be authorized or not. Hence schemes which support both AAA services and mobility have been emerged. These schemes enable access of the mobile node to be authorized by visited networks through AAA as well as to perform a home registration during AAA procedure. However, they introduce lots of signal messages and long handover latency during handover, since Route Optimization mode for MIPv6 is performed using Return Routability procedure. Especially, the long handover latency is a critical problem in real-time communication such as voice over IP (VoIP). To solve these problems, we propose an optimized scheme which performs Route Optimization mode using the AAA infrastructure between the home agent and a correspondent node instead of Return Routability procedure. "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, 18-Nov-07, A framework for the exchange of capabilities in HELD is described. Capabilities for enabling device-based measurements and device-based location generation are described. "Unified L2 Abstractions for L3-Driven Fast Handover", Fumio Teraoka, 20-Feb-08, This draft proposes unified L2 abstractions for L3-driven fast handovers. For efficient network communication, it is vital for a protocol layer to know or utilize other layer's information such as a form of L2 triggers. However, each protocol layer is basically designed independently. Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers. This draft defines nine kinds of L2 abstractions in the form of "primitives" to achieve fast handovers in the network layer as a means of solving the problem. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the "primitives". This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. "Delay-Tolerant Networking Custodial Multicast Extensions", Susan Symington, 15-Nov-07, 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, 8-Nov-07, This document defines an additional administrative record type to be used with the Bundle Protocol [2] within the context of a Delay- Tolerant Network architecture [5]. This new administrative record type, called a Bundle-in-Bundle Encapsulation Administrative Record, is designed to be used to encapsulate one or more bundles inside of another bundle. When an administrative record of the bundle-in- bundle encapsulation type is carried as the payload of a bundle, it provides a mechanism for transmitting one or more bundles as part of the payload of another bundle. This administrative record type is expected to be of general use 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 administrative record type. "Delay-Tolerant Networking Previous Hop Insertion Block", Susan Symington, 8-Feb-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. "Sender Policy Framework: SPF Options", Frank Ellermann, 15-Nov-07, In discussions about the Sender Policy Framework (SPF) users often wanted to add optional properties to their sender policies. The modifier "match_subdomains=yes" made it into early SPF drafts. This memo proposes a general syntax for a modifier "op=" for this purpose. "The Hypertext Transfer Protocol (HTTP) Entity Tag ("ETag") Response Header in Write Operations", Julian Reschke, 25-Oct-07, The Hypertext Transfer Protocol (HTTP) specifies a state identifier, called "Entity Tag", to be returned in the "ETag" response header. However, the description of this header for write operations such as PUT is incomplete, and has caused confusion among developers and protocol designers, and potentially interoperability problems. This document explains the problem in detail and suggests both a clarification for a revision to the HTTP/1.1 specification (RFC2616) and a new header for use in responses, making HTTP entity tags more useful for user agents that want to avoid round-trips to the server after modifying a resource. Editorial Note (To be removed by RFC Editor before publication) Distribution of this document is unlimited. Please send comments to the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http-wg@w3.org [1], which may be joined by sending a message with subject "subscribe" to ietf-http-wg-request@w3.org [2]. Discussions of the HTTP working group are archived at . XML versions, latest edits and the issues list for this document are available from . "Unique Channel Bindings for TLS", Jeffrey Altman, Nicolas Williams, 8-Nov-07, This document defines a form of channel bindings for TLS (Transport Layer Security), namely the concatenation of the initial client and server "finished" messages for a TLS connection. "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 BCPs", Saverio Niccolini, Eric Chen, Jan Seedorf, 22-Feb-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. "SAM Problem Statement", Shivanand Kadadi, John Buford, 17-Mar-08, We describe the generally expected behavior of a scalable and adaptive multicast architecture, leaving further details to separate documents on requirements and the SAM design space. This document is a starting point for discussions of feasibility, priority, and deployability. "Dynamic Feature Extensions to the Presence Information Data Format Location Object (PIDF-LO)", Singh Vishal, Henning Schulzrinne, Hannes Tschofenig, 19-Nov-07, 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. This document extends 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. The document also specifies mechanisms to carry multiple moving object's status elements and proposes a mechanism to indicate the type of the PIDF-LO content. "Channel bindings for HTTP+TLS transport", Leif Johasson, 18-Nov-07, This document specifies a channel concept for HTTP with TLS and a representation of that channel which can be used by protocols which use channel bindings to delegate session protection to lower layers. "Presentation of Text Conversation in realtime and en-bloc form", Gunnar Hellstrom, Norman Williams, Gregg Vanderheiden, 29-Jan-08, This specification defines methods for presentation of a text conversation with focus on the real-time features. The aim is to give the participants in a conversation a good opportunity to perceive the real-time flow of the conversation and also provide a display of the history of the conversation that makes it easy to read. Both two-party and multi-party situations are defined. "Transporting User to User Call Control Information in SIP for ISDN Interworking", Alan Johnston, Joanne McMillen, 15-Jan-08, Several approaches to transporting the ITU-T Q.931 User to User Information Element (UU IE) data in SIP have been implemented. 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 document discusses the approaches and recommends a new header field User-to-User be standardized. An example application of an Automatic Call Distributor (ACD) in a contact center is given. "PE-based Multicast Framework for IPv6 Transition", Mingwei Xu, Yong Cui, Chris Metz, 19-Nov-07, The Internet sometimes faces such scenario that: a set of customer networks are connected to a transit core who delivers messages for them, to communicate with each other; the massages from one customer network to another are tunneled to pass through the transit core. The tunnels are known as "softwires". It has been described in [I-D.ietf-softwire-mesh-framework] . The customer networks may also need to run IP multicast applications across the transit core. This memo provides a PE-based multicast framework for IPv6 transition. "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. "IMAP4 extension for named searches (filters)", Curtis King, Alexey Melnikov, 28-Jan-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. "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. "Application of PANA framework to DSL networks", Lionel Morand, 25-Feb-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. "IPv6 Address Specific BGP Extended Communities Attribute", Yakov Rekhter, 8-Apr-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. "Pseudowire (PW) Redundancy", Praveen Muley, Matthew Bocci, Jonathan Newton, 19-Nov-07, This document describes a few scenarios 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 bit is needed to indicate the preferential forwarding status of active or standby for each PW in the redundancy set as defined in [7]. "The record-jar Format", Addison Phillips, 20-Feb-08, The record-jar format provides a method of storing multiple records with a variable repertoire of fields in a text format. This document provides a description of the format. Comments are solicited and should be addressed to the mailing list 'record-jar@yahoogroups.com' and/or the author. "Atom Publishing Protocol Feature Discovery", James Snell, 27-Oct-07, This document introduces extensions to the Atom Publishing Protocol Service Document format for expressing metadata about the behaviors, functions and capabilities supported by an Atom Publishing Protocol collection. "URI Template", Joe Gregorio, 1-Apr-08, A URI Template is a compact sequence of characters used for the construction of URIs. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI, along with guidelines and security considerations for the use of URI Templates on the Internet. The URI Template syntax allows for the construction of strings that are a superset of URIs, allowing an implementation to process any URI Template without knowing the scheme-specific requirements of every possible resulting URI. "Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer", Jon Green, Douglas Stebila, 15-Oct-07, 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, 18-Nov-07, 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. "Contexts for IMAP4", Dave Cridland, Curtis King, 21-Jun-07, The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results which can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. "Session Description Protocol (SDP) Offer/Answer Model For Media Control Protocol", Xavier Marjou, Priya Rajagopal, Mikhael Said, Sam Ganesan, 24-Feb-08, This draft presents an approach to content on demand that relies on a session management protocol and SDP offer/answer model [6] to establish media control and media delivery flows. this approach would be beneficial for some applications such as IPTV or applications that require a mix of real-time and streaming flows. "Multicast VPN Scalability Benchmarking", Silvija Dry, 9-Nov-07, Multicast VPN (MVPN) is a service deployed by VPN service providers to enable their customers to use IP multicast applications over VPNs. With the increased popularity the scalability of deploying such a service is becoming of a great interest. This document defines standard metric and test methodology for characterizing and comparing control plane MVPN scalability of Provider Edge (PE) devices that implement MVPN service. "Atom Bidirectional Attribute", James Snell, 19-Oct-07, This document adds a new attribute to the Atom Syndication Format used to indicate the base directionality of directionally-neutral characters. "Delay-Tolerant Networking Retransmission Block", Susan Symington, 8-Nov-07, 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 replayed bundles to detect and delete unauthorized bundle replays but forward authorized custody-based bundle retransmissions. This document defines the format and processing of this new Retransmission Block. "Applying Loose Routing to Session Initiation Protocol (SIP) User Agents (UA)", Jonathan Rosenberg, 25-Jan-08, A key part of the behavior of the Session Initiation Protocol (SIP) is that SIP proxies rewrite the Request-URI as a request moves throughout the network. Over the years, experience has shown this to be problematic. It makes it difficult to use Request URI for service invocation, complicates emergency services, makes it more complex to support aliases, and so on. Architecturally, it confounds the concepts of address and route. This document proposes to change this through a new mechanism called UA loose routing. "Hypertext Transfer Protocol -- HTTP/1.1", Roy Fielding, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Yves Lafon, Julian Reschke, 18-Nov-07, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [RFC2324]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC2616.Editorial Note (To be removed by RFC Editor before publication) Distribution of this document is unlimited. Please send comments to the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http-wg@w3.org [1], which may be joined by sending a message with subject "subscribe" to ietf-http-wg-request@w3.org [2]. Discussions of the HTTP working group are archived at . XML versions, latest edits and the issues list for this document are available from . The purpose of this document is to revise [RFC2616], doing only minimal corrections. For now, it is not planned to advance the standards level of HTTP, thus - if published - the specification will still be a "Proposed Standard" (see [RFC2026]). The current plan is to incorporate known errata, and to update the specification text according to the current IETF publication guidelines. In particular: o Incorporate the corrections collected in the RFC2616 errata document () (most of the suggested fixes have been applied to draft 01 [3]). o Incorporate corrections for newly discovered and agreed-upon problems, using the HTTP WG mailing list as forum and as issues list. o Update references, and re-classify them into "Normative" and "Informative", based on the prior work done by Jim Gettys in . This document is based on a variant of the original RFC2616 specification formatted using Marshall T. Rose's "xml2rfc" tool (see ) and therefore deviates from the original text in word wrapping, page breaks, list formatting, reference formatting, whitespace usage and appendix numbering. Otherwise, it is supposed to contain an accurate copy of the original specification text. See for a comparison between both documents, as generated by "rfcdiff" (). "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", Peter Saint-Andre, 29-Oct-07, This document describes 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. "How to Share Transaction Fraud (Thraud) Report Data", David M'Raihi, 19-Feb-08, This document describes a data-format and protocol for defining and exchanging Transaction Fraud (Thraud) Report Data. It extends the INCH WG's IODEF XML [IODEF] incident reporting format. Both inbound (Thraud Reports) and outbound (Thraud Watchlists) mechanisms are presented. This work has been endorsed by the Initiative for Open AuTHentication [OATH]. "Updates to Asserted Identity in the Session Initiation Protocol (SIP)", John Elwell, 16-Nov-07, 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 this header field with the SIP UPDATE, MESSAGE or PUBLISH methods, and is unclear on the use of this header field in responses. This document extends RFC 3325 to cover these situations. This work is being discussed on the sipping@ietf.org mailing list. "Lightweight SIP Toolkit for Peer-to-Peer and Basic Client-Server Systems", Henry Sinnreich, Alan Johnston, Eunsoo Shim, Kundan Singh, 25-Feb-08, This memo discusses the usage scenario of SIP where all the applications reside in the endpoints. This is an alternative to the current usage of SIP where the services reside in the network. The use of SIP where the applications reside in the endpoints is applicable to P2P SIP networks and also to client-server networks. Such an approach reduces the number of required SIP related standards (as by spring 2008) from roughly 100 to about 11. Successful IP communications must also include the relevant standards for NAT traversal, some of which are not directly related to SIP and also several standards for security. These standards are included in the simple usage scenario for SIP as well. "Using DHCPv6 for Prefix Delegation in IEEE 802.16 Networks", Frank Xia, Behcet Sarikaya, 17-Nov-07, In the 802.16 Per-MS interface prefix model, one prefix can only be assigned to one interface of a mobile station by an access router and different mobile stations can't share a prefix. Managing Per-MS interface prefixes is likely to increase the processing load at the access router. Based on the idea that DHCPv6 servers can manage prefixes as well as addresses, we propose a new technique in which the access router offloads delegation and release tasks of the prefixes to an DHCPv6 server. The access router first requests a prefix for an incoming mobile station to the DHCPv6 server. The access router next advertises the prefix information to the mobile station with a Router Advertisement message. When the mobile station hands off, the prefix is returned to the DHCPv6 server. We also describe how AAA servers can help in prefix delegation. "Peer-to-Peer SIP Implementation Report", Martin Stiemerling, Marcus Brunner, 19-Nov-07, This memo is an implementation report about the peer-to-peer SIP system developed in the European IST Ambient Networks research project. This system replaces the traditional SIP proxy-registrar function with a distributed lookup mechanism, adds overlay functionality to the SIP signalling and to RTP traffic, takes care about media/packet relay lookup and insertion into the SIP/RTP paths, plus automatic adaptation of the voice transmission according to changing network conditions. Standard, unmodified SIP user agents are used for communication. The presented system is work in progress and this memo is an attempt to gather IETF community feedback about the described approach. "An updated IDNA criterion for right-to-left scripts", Harald Alvestrand, Cary Karp, 14-Feb-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. "Pre-Congestion Notification Using Single Marking for Admission and Termination", Anna Charny, Xinyang Zhang, Francois Le Faucheur, Vassilis Liatsos, 18-Nov-07, Pre-Congestion Notification described in [I-D.eardley-pcn-architecture] and earlier in [I-D.briscoe-tsvwg-cl-architecture] approach proposes the use of an Admission Control mechanism to limit the amount of real-time PCN traffic to a configured level during the normal operating conditions, and the use of a Flow Termination mechanism to tear-down some of the flows to bring the PCN traffic level down to a desirable amount during unexpected events such as network failures, with the goal of maintaining the QoS assurances to the remaining flows. In [I-D.eardley-pcn-architecture], Admission and Flow Termination use two different markings and two different metering mechanisms in the internal nodes of the PCN region. This draft proposes a mechanism using a single marking and metering for both Admission and Flow Termination, and presents an analysis of the tradeoffs. A side- effect of this proposal is that a different marking and metering Admission mechanism than that proposed in [I-D.eardley-pcn-architecture] may be also feasible, and may result in a number of benefits. In addition, this draft proposes a migration path for incremental deployment of this approach as an intermediate step to the dual-marking approach. "Session Initiation Protocol (SIP) Overload Control", Volker Hilt, Indra Widjaja, Daryl Malas, Henning Schulzrinne, 22-Feb-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 proposes new overload control mechanisms for SIP. "IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications", James Polk, 19-Nov-07, This document creates and IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace "sos" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. "Configuring the Differentiated Services Codepoint of Session Description Protocol Established Media Streams", James Polk, 23-Feb-08, The Session Description Protocol (SDP) offer/answer model currently has no mechanism for dynamic configuration of the Differentiated Services Codepoints (DSCP) for the media streams endpoints establish. This document creates such a mechanism within SDP, as granular as at the media stream level where more than one stream can be in an offer/answer exchange, to set a particular DSCP for the desired Per Hop Behavior (PHB) of a media stream. This same mechanism can change a DSCP of an existing stream based on dynamic network conditions. "Methodology for Benchmarking SIP Networking Devices", Scott Poretsky, Vijay Gurbani, Carol Davids, 18-Nov-07, This document describes the methodology for benchmarking Session Initiation Protocol (SIP) performance as described in Terminology document [5]. The methodology and terminology are to be used for benchmarking signaling plane performance with varying signaling and media load. Both scale and establishment rate are measured by signaling plane performance. The SIP Devices to be benchmarked may be a single device under test (DUT) or a system under test (SUT). Benchmarks can be obtained and compared for different types of devices such as SIP Proxy Server, SBC, P-CSCF, and Server paired with a Firewall/NAT device. "Extensions to the IODEF-Document Class for Phishing, Fraud, and Other Crimeware", Patrick Cain, David Jevans, 25-Oct-07, 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 "Discovering, Querying, and Controlling Firewalls and NATs", Dan Wing, Jonathan Rosenberg, Hannes Tschofenig, 16-Oct-07, A drawback with many NAT UDP hole punching techniques is the keepalive traffic necessary to keep the UDP binding open. It it necessary to send keepalives frequently because it is not possible to determine or modify the NAT's binding lifetime. This keepalive traffic causes server load and additional network traffic, which is especially problematic with battery-operated wireless devices. This document describes two mechanisms to discover NATs and firewalls and a mechanism to query and control their binding lifetime. With these mechanisms, UDP binding discovery and UDP keepalive traffic can be reduced to involve only the necessary NATs or firewalls. This eliminates the keepalive traffic to servers, and vastly reduces keepalive traffic across the network. At the same time, backwards compatibility with NATs and firewalls that do not support this specification is retained, which allows for incremental deployment of this mechanism. This document is discussed on the SAFE mailing list, . "HELD Identity Extensions", James Winterbottom, 19-Nov-07, 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 appropriate in many environments. However, when an entity acting on behalf of the Target would like to request location information then the source IP address of the request will lead to wrong results. In other cases the IP address is not the only identifier that serves as an input to the location determination procedure. 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. As such, this extension is used in conjunction with HELD to provide Target identification. Examples and usage in HELD message syntax are provided. "A Process for Handling Essential Corrections to the Session Initiation Protocol (SIP)", Keith Drage, 19-Nov-07, 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. "Guidelines for the order of Information Elements", Hitoshi Irino, 24-Feb-08, This draft provides guidelines for the order of Information Elements for Templates of the IPFIX protocol. This draft would like to be referred as supplementary document for implementations. This draft provides the referential order for Information Elements in order to increase efficiency of the Collecting Processes and Exporting Processes. "The SIEVE mail filtering language - extension for accessing mailbox metadata", Alexey Melnikov, 21-Dec-07, This memo defines and extension to the SIEVE mail filtering language (RFC 3028) for accessing mailbox and server annotations (variables). "HTTP State Management Mechanism v2", Yngve Pettersen, 24-Feb-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, 25-Feb-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 new IPv6 extension headers. "Experience of implementing NETCONF over SOAP", Iijima Tomoyuki, Yoshifumi Atarashi, Hiroyasu Kimura, Makoto Kitani, Hideki Okita, 20-Feb-08, This document describes how we developed a SOAP-based NETCONF client and server. In the case of using SOAP as a transport protocol of NETCONF, various kinds of development tools are available. By making full use of those tools, developers' workloads are significantly reduced. We developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document is aimed at providing knowledge about development guidelines gained from the implementation experience of a SOAP-based NETCONF client and server. "The Unicode Codepoints and IDNA", Patrik Faltstrom, 18-Feb-08, This document specifies rules for deciding whether a codepoint, considered in isolation, is a candidate for inclusion in an Internationalized Domain Name. It is part of the specification of IDNA200X. "RSVP Extensions for Path Key Support", Richard Bradford, JP Vasseur, 24-Feb-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. To preserve confidentiality of topology with each AS, the PCE supports a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS). This document describes the addition of this information to Resource Reservation Protocol (RSVP) signaling by inclusion in the Explicit Route Object (ERO) and Record Route Object (RRO). "Internationalizing Domain Names for Applications (IDNA): Issues, Explanation, and Rationale", John Klensin, 6-Feb-08, A recent IAB report identified issues that have been raised with Internationalized Domain Names (IDNs). Some of these issues require tuning of the existing protocols and the tables on which they depend. Based on intensive discussion by an informal design team, this document provides an overview some of the proposals that are being made, provides explanatory material for them and then further explains some of the issues that have been encountered. "Credential Protection Ciphersuites for Transport Layer Security (TLS)", Ibrahim Hajjeh, 2-Apr-08, The Transport Layer Security (TLS) supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. For each mode, TLS specifies a set of cipher suites. Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. The authentication is usually based on either preshared keys or public key certificates. If a public key certificate is used to authenticate the TLS client during the TLS Handshake, the TLS client credentials are sent in clear text over the wire. Thus, any observer can determine the credentials used by the client, learn who is reaching the network, when, and from where, and hence correlate the client credentials to the connection location. This document defines a set of cipher suites to add client credential protection to the TLS protocol. This is useful especially if TLS is used in wireless environments or to secure remote access. By negotiating one of the ciphersuites described in this document, 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. "IODEF/RID over SOAP", Brian Trammell, Kathleen Moriarty, 25-Feb-08, Documents intended to be shared among multiple constituencies must share a common format and transport mechanism. The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange. This draft outlines the SOAP wrapper for all IODEF documents and extensions to facilitate an interoperable and secure communication of documents. The SOAP wrapper allows for flexibility in the selection of a transport protocol. The transport protocols will be provided through existing standards and SOAP binding, such as SOAP over HTTP/TLS and SOAP over BEEP. "Real-time Inter-network Defense", Kathleen Moriarty, 25-Feb-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. "Segmented Multicast MPLS/BGP VPNs", Maria Napierala, 25-Feb-08, This document describes inter-site signaling procedures in MPLS/BGP IP VPNs that allow the same multicast stream to flow simultaneously on multiple inter-PE paths without duplicates being sent to receivers. Those procedures are independent of multicast tunnel technology used in service provider network as well as of the protocol used to exchange multicast signaling among PE's. The document specifies necessary information elements and their exchange process for the desired MVPN operation. "Synchronizing Location-to-Service Translation (LoST) Servers", Henning Schulzrinne, 25-Feb-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. "OSPF Extensions for Dynamic Multi-segment Pseudo Wires", Matthew Bocci, Dimitri Papadimitriou, Alex Zinin, Mustapha Aissaoui, Andrew Dolganow, Yuji Kamite, Luca Martini, Frederic JOUNAY, 27-Feb-08, Multi-segment pseudowires have been defined to enable emulated layer 1 and layer 2 services to be delivered from an IP based packet switched network over a sparse mesh of PSN tunnels and PW control protocol sessions. MS-PWs can be used to scale PW based networks over both a single AS, or between multiple ASs, and there is a particular need to be able to dynamically route MS-PWs through a given AS to reach PEs at or beyond the edge of the AS, where the route of the PW through each AS needs to be automatically determined. This draft proposes extensions to OSPF to enable the automatic advertisement of summarized PW FECs, thus enabling the dynamic routing of MS-PWs across an OSPF domain. "IPsec Gateway Failover and Redundancy - Problem Statement and Goals", Vidya Narayanan, 4-Dec-07, Recovering from failure of IPsec gateways maintaining large numbers of SAs may take several minutes, if they need to re-establish the IPsec SAs by re-running the key management protocol, IKEv2. A similar problem arises in the event of a network outage resulting in the failure of several gateways and servers. The latency involved in this approach is significant, leading to a need for a faster and yet secure failover solution. This document describes the problem statement and the goals for an IPsec/IKEv2 gateway failover/ redundancy solution. "Fast Macro Mobility Handovers in HMIPv6", Youngsong Mun, 2-Nov-07, 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, 20-Feb-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)", Oded Koren, 7-Jan-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. "Signaling TO Prevent SPIT (SPITSTOP) Reference Scenario", Saverio Niccolini, Jan Seedorf, 15-Feb-08, This memo discusses the need for standards that support SPam over Internet Telephony (SPIT) prevention applications. After explaining the general need for SPIT prevention applications the memo provides a reference scenario for potential communication between entities that may be involved in SPIT prevention. Within this scenario the need for standardizing communication is analyzed for each pair of communicating entities. The analysis is intended to serve as a starting point for discussing the requirements for signaling standards as well as for architectural considerations, that support SPIT prevention applications. This memo is not intended to suggest any solution of SPIT signaling issues. Such work, if necessary at all, should be object of separate documents. "Hybrid Overlay Multicast Framework", John Buford, 25-Feb-08, We describe an experimental framework for constructing SAM sessions using hybrid combinations of Application Layer Multicast, native multicast, and multicast tunnels. We leverage AMT relay and gateway elements for interoperation between native regions and ALM regions. The framework allows different overlay algorithms and different ALM control algorithms to be used. "IEEE 802.21 Basic Schema", Kenichi Taniuchi, Yoshihiro Ohba, Subir Das, 25-Feb-08, This document describes the basic schema for IEEE 802.21 Media- Independent Information Service, an RDF (Resource Description Framework) schema defined in IEEE 802.21. 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, 7-Apr-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. "ENUM Registry Interface Requirements", Edward Lewis, 16-Nov-07, An ENUM registry interacts with various elements to maintain what is essentially a telephone number to uniform (or a more modern version) resource identifier. The interfaces needed are identified in this requirements document, as well as the requirements for the more generic interfaces. "Locator/ID Separation Protocol (LISP)", Dino Farinacci, 29-Feb-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, 28-Oct-07, 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, 28-Oct-07, This memo describes the anonymous layers identifiers in mobility and multi-homing problem statement. "Progress notifications for HTTP", Andrien de Croy, 31-Oct-07, This document specifies extenions to HTTP to allow progress messages for user-agents during lengthy transactions. "Requirements for the XCON-DCON Synchronization Protocol", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 23-Jan-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, 23-Jan-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, 23-Jan-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. "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", Alan DeKok, 20-Mar-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. "draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt", Diego Caviglia, Dan Li, 18-Feb-08, In a transport network scenario, where Data Plane connections controlled either by GMPLS (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 valuable option. This applies especially when a GMPLS based Control Plane is first introduced into an existing network and there may be the need, from a Carrier point of view, to pass under GMPLS control existing connections already set up over Data Plane. In other terms, such operation could 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 provides a minor extension to GRSVP-TE signaling protocol, within GMPLS architecture, to enable such connection ownership transfer and describes the proposed procedures. "TCP Robustness in Persist Condition", Mahesh Jethanandani, Murali Bashyam, 19-Oct-07, This document describes how a connection can remain infinitely in persist condition, and its Denial of Service (DoS) implication on the system, if there is no mechanism to recover from this anomaly. "PSTN scope of PCN Charter", Stuart Goldman, Robert Schafer, Frank Suraci, Bob Schaefer, 12-Feb-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, 6-Nov-07, 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, 14-Nov-07, 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. "Container Option for Server Configuration", Ralph Droms, 13-Nov-07, 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. "Secure Media Recording and Transcoding with the Session Initiation Protocol", Dan Wing, Francois Audet, Steffen Fries, Hannes Tschofenig, Alan Johnston, 24-Feb-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. "Mobile Node Agnostic Fast Handovers for Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya, 17-Nov-07, Proxy Mobile IPv6 (PMIPv6) is a mobile node agnostic mobility management protocol, that is, a mobile node does not implement any mobility management protocol. This document proposes an enhancement to PMIPv6 protocol in order to improve layer 3 handover performance and to transfer context borrowing some ideas from Fast Handovers for Mobile IPv6 (FMIPv6) protocol. In predictive mode, the previous mobile access gateway (PMAG) transfers context to the next MAG (NMAG) using Handover Indication (HI) message, while in reactive mode, NMAG uses Fast Binding Update (FBU) to request context from PMAG. A bi- directional tunnel is established between PMAG and NMAG to transfer packets during handover. "Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links", Frank Xia, Behcet Sarikaya, 22-Feb-08, The Mobile IPv6 Fast Handovers (FMIPv6) specification currently does not explicitly define prefix management over point-to-point links when a Mobile Node (MN) uses a prefix to formulate a new Care-of- Address (CoA). In this document a mechanism is proposed for assigning unique prefixes to the MN by the Previous Access Router (PAR). The New Access Router (NAR) dynamically assigns an unique prefix called dedicated prefix to any MN that is performing a handover. Both reactive and predictive modes of FMIPv6 are explained. "Public Key Cryptography Based User-to-User Authentication - (PKU2U)", Larry Zhu, Jeffrey Altman, 28-Jan-08, This document defines the public key cryptography based user-to-user authentication protocol - PKU2U. This mechanism provides security services in peer to peer networking environments without requiring a Kerberos Key Distribution Center (KDC). Furthermore, the binding of PKU2U for the Generic Security Service Application Program Interface (GSS-API) per RFC2743 is defined based on RFC4121. "Supporting Multiple Path Routing in the Session Initiation Protocol (SIP)", Dale Worley, 18-Nov-07, 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 TCP Test to Allow Senders to Identify Receiver Non-Compliance", T Moncaster, Bob Briscoe, Arnaud Jacquet, 8-Nov-07, The TCP protocol relies on receivers sending accurate and timely feedback to the sender. Currently the sender has no means to verify that a receiver is correctly sending this feedback according to the protocol. A receiver that is non-compliant has the potential to disrupt a sender's resource allocation, increasing its transmission rate on that connection which in turn could adversely affect the network itself. This document presents a two stage test process that can be used to identify whether a receiver is non-compliant. The tests enshrine the principle that one shouldn't attribute to malice that which may be accidental. The first stage test causes minimum impact to the receiver but raises a suspicion of non-compliance. The second stage test can then be used to verify that the receiver is non-compliant. This specification does not modify the core TCP protocol - the tests can either be implemented as a test suite or as a stand-alone test through a simple modification to the sender implementation. Status By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Changes from previous drafts (to be removed by the RFC Editor) From -01 to -02: A number of changes made following an extensive review from Alfred Hoenes. These were largely to better comply with the stated aims of the previous version but also included some tidying up of the protocol details and a new section on a possible unwanted interaction. From -00 to -01: Draft rewritten to emphasise testing for non-compliance. Some changes to protocol to remove possible unwanted interactions with other TCP variants. Sections added on comparison of solutions and alternative uses of test. "A BEEP Binding for the HELD Protocol", Martin Thomson, James Winterbottom, 19-Nov-07, 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, 13-Nov-07, 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. "Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in Generalized MPLS Networks", Guowu Xie, 3-Dec-07, Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for the future data transmission network. The GMPLS has been developed to control and cooperate 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 dynamically provisioned connections is increasing because optical networks are being deployed in metro area. 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 dynamical LSP setup/release performance. These metrics can depict the features of the GMPLS network in LSP dynamic provisioning. They can also be used in operational networks for carriers to monitor the control plane performance in realtime. "Client-Friendly Cross-Realm Model for Kerberos 5", Ken'ichi Kamada, Shoichi Sakane, 16-Nov-07, This document proposes a cross-realm traversal model, which is suitable for resource-limited clients, for Kerberos Version 5. This model relieves the clients of the traversal cost by two means. One moves the cost of consecutive Ticket-Granting Service (TGS) exchanges from clients to Key Distribution Centers (KDCs). The other reduces the traversal cost itself by generating a direct inter-realm relationship between two realms. The document describes behavior of clients and KDCs, but does not specify any wire format, which need to be specified separately. "A Uniform Resource Identifier for Geographic Areas ('geo' URI)", Alexander Mayrhofer, Christian Spanring, 18-Feb-08, This document specifies an Uniform Resource Identifier (URI) for geographic areas using the 'geo' scheme name. A 'geo' URI provides a compact, human-readable, and protocol independent way to identify an area by means of a hierarchical tiling scheme. "Vouch By Reference", Paul Hoffman, John Levine, Arvel Hathcock, 19-Feb-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. "Simulations Results for 3sm", Jozef Babiarz, Xiao-Gao Liu, Siavash Rahimi, 19-Nov-07, This document describes the simulation setups and results for testing the Three State PCN Marking approach. Simulations done to date, demonstrate that the three state PCN marking approach has certain ability to support admission control and flow termination of real- time application flows at the congestion point(s) of the PCN-enabled network. The real-time traffic used in the simulation covers voice and video traffic with large and small numbers of flows. "Methodology for Benchmarking LDP Convergence", Jay Karthik, Rajiv Papneja, Mohan Nanduri, 19-Feb-08, This document describes methodology which includes procedure and network setup, for benchmarking Label Distribution Protocol (LDP) [RFC5036]Convergence. The proposed methodology is to be used for benchmarking LDP convergence independent of the underlying IGP used (OSPF or ISIS) and the LDP operating modes. The terms used in this document are defined in a companion draft [LDP-Term]. "Quick-Start for Datagram Congestion Control Protocol (DCCP)", Gorry Fairhurst, Arjuna Sathiaseelan, 13-Nov-07, 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. "FCAST: Scalable Object Delivery on top of the ALC Protocol", Vincent Roca, 25-Feb-08, This document introduces the FCAST object (e.g. file) delivery application on top of the ALC reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service. "Principles of Internet Host Configuration", Bernard Aboba, Dave Thaler, Loa Andersson, 11-Oct-07, 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. "GMPLS control of Ethernet PBB-TE", Don Fedyk, 20-Nov-07, This memo is complementary to [ARCH] and describes how a GMPLS control plane may be applied to the Provider Backbone Bridges Traffic Engineering (PBB-TE) [IEEE 802.1Qay] amendment to 802.1Q and how GMPLS can be used to configure VLAN-aware Ethernet switches in order to establish Ethernet point to point (P2P) and P2MP MAC switched paths and P2P/P2MP VID based trees. This document supports, but does not modify, the standard IEEE data. "Media Gateway Control Protocol Voiceband Data Package and General Purpose Media Descriptor Parameter Package", Sandeep Sharma, Joe Stone, Rajesh Kumar, 16-Nov-07, 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, 18-Nov-07, 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. "An Extension to Session Initiation Protocol (SIP) Events for Pausing and Resuming Notifications", Mohammad Vakil, Sriram Parameswar, 12-Mar-08, The Session Initiation Protocol (SIP) events framework enables a subscriber to receive asynchronous notification of various events from other SIP user agents. It defines mechanisms to create, refresh, terminate subscriptions. This framework also defines mechanism to fetch (poll) an event state of a resource without creating persistent subscriptions. There is no mechanism to temporarily pause the notifications, while still maintaining a subscription on the server. This lack of functionality sometime results in a lot of superfluous notification traffic, and put unnecessary load on the server. This draft defines an extension to SIP events that allows the subscriber to pause, un-pause notifications, and be able to perform fetch (poll) subscriptions within an established (created) subscription dialog. "VPLS Interoperability with Provider Backbone Bridges", Ali Sajassi, 20-Nov-07, 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 is being worked on in IEEE 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 MPLS access or IEEE 802.1ad (aka QinQ) Ethernet access and interoperability among them. "Quality Measurement Requirements for Tunneling Protocols", Yutaka Kikuchi, Satoru Matsushima, Kenichi Nagami, Satoshi Uda, 12-Nov-07, This draft describes the necessary requirements to passively measure the quality of end-to-end tunnels and to monitor them via applicable ways. This feature is crucial for Service Providers (SPs), especially who provide transports to users using tunnels. "draft-yasukawa-pce-p2mp-app-02.txt", Seisho Yasukawa, Adrian Farrel, 15-Feb-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. "Proxy Shim6 (P-Shim6)", Marcelo Bagnulo, 22-Feb-08, This draft discusses extensions to the shim6 architecture to support shim6 proxies that would allow the provision of the following capabilities: o Provide Upper Layer Identifier portability. o Provide Traffic Engineering policy enforcement. o Off-load of the shim6 context management from the actual peers of the communication. o Enable legacy IPv6 nodes located in the multihomed site to obtain full multihoming support (no modification of the end nodes). "PMIPv6 Route Optimization Protocol", Behcet Sarikaya, Xia Qin, Andy Huang, Wenson Wu, 14-Nov-07, This document defines route optimization protocol for Proxy Mobile IPv6. Proxy home test, concurrent proxy care-of test and handover procedures based on Enhanced Route Optimization for Mobile IPv6 are explained. Mobile access gateway uses cryptographically generated home addresses so that no more home test is needed after the initial home test. Handover home keygen token is used during handover in order to eliminate home test for the next mobile access gateway. The protocol also supports IPv4 transport network operation. "Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages", Vladislav Marinov, 13-Feb-08, This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG notifications. "SASL Yet Another Password Mechanism", Kurt Zeilenga, 20-Nov-07, This document describes a password authentication mechanism, called YAP-SHA-256, for use in protocols which support Simple Authentication and Security Layer (SASL) framework. The mechanism relies on security services provided by a lower layer, such as Transport Layer Security (TLS), to protect the authentication exchange, and subsequent application data exchange, from common attacks. The YAP-SHA-256 mechanism may be viewed as an alternative to other password-based SASL mechanism, such as PLAIN, CRAM-MD5, and DIGEST-MD5. "Authentication Extensions for the Dynamic Host Configuration Protocol", Richard Pruss, Glen Zorn, Roberta Maglione, Li Yizhou, 18-Nov-07, This document defines Dynamic Host Configuration Protocol (DHCP) extensions that provide for end-user authentication prior to configuration of the host. The primary applicability is within a Digital Subscriber Line (DSL) Broadband network environment in order to enable a smooth migration from the Point to Point Protocol (PPP). "Media Description for IKE in the Session Description Protocol (SDP)", Makoto Saito, Dan Wing, 3-Dec-07, 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. "The Multiple Appearance Feature using the Session Initiation Protocol (SIP)", Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan, Paul Pepper, Anil Kumar, 25-Feb-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 Mesh Routing", Dominik Kaspar, Eunsook Kim, Carles Gomez, Carsten Bormann, 1-Apr-08, This document provides the problem statement for 6LoWPAN mesh routing. It also defines the requirements for 6LoWPAN mesh routing considering the low-power characteristics of the network and its devices. "Document: draft-otani-ccamp-gmpls-routing-interlink-01.txt", Tomohiro Otani, Kenichi Ogaki, Shuichi Okamoto, 13-Nov-07, This draft states the problem of the current generalized multi- protocol label switching (GMPLS) routing in order to deal with inter- domain TE links for GMPLS inter-domain signaling. Since the GMPLS signaling protocol introduces bi-directional label switched path (LSP) creation mechanism, an ingress node (or a path computation element) searches for the bidirectional route in the traffic engineering database (TED). Considering the GMPLS inter-domain path creation, the TED contains only outgoing TE information of inter- domain links and will not be able to confirm the validity of the incoming inter-domain links. In order to solve this issue, we describe the GMPLS inter-domain routing requirement in support of exchanging of inter-domain TE link information. "The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use with IPsec", Akihiro Kato, Masayuki Kanda, Tetsu Iwata, 25-Feb-08, This memo specifies two new algorithms. One is the usage of Cipher- based Message Authentication Code (CMAC) with Camellia block cipher on the authentication mechanism of the IPsec Encapsulating Security Payload and Authentication Header protocols. This algorithm is called Camellia-CMAC-96. Latter is pseudo-random function based on CMAC with Camellia block cipher for Internet Key Exchange. This algorithm is called Camellia-CMAC-PRF-128. "A context mechanism for controlling caching of HTTP responses", Yngve Pettersen, 24-Feb-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 P2PSIP", Marcin Matuszewski, Jan-Erik Ekberg, Pekka Laitinen, 19-Nov-07, This document presents main security requirements for the Peer-to- Peer SIP (P2PSIP) architecture and its components. This document also analyses security threats in P2PSIP. Typical security ontology is used as classification for the threats. "Network In Node Advertisement", Pascal Thubert, Ryuji Wakikawa, Carlos Bernardos, Roberto Baldessari, Jean Lorchat, 4-Feb-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. This cloud is called a MANEMO Fringe Stub (MFS). It is expected that networking in the MFS 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 MFS 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 MFS. This form of local routing is useful for Route Optimization (RO) between Mobile Routers that are communicating directly in a portion of the MFS. 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 where an embedded network is abstracted as a Host for 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. "Stream Control Transmission Protocol (SCTP) Readdressing Retransmission Trigger", Michio Honda, 22-Feb-08, Stream Control Transmission Protocol (SCTP)[RFC4960] can support mobility by utilizing the multi-home feature and the Dynamic Address Reconfiguration extension (ADDIP)[RFC5061]. By leveraging this feature, applications that use SCTP can continue communication without terminating it when the mobile node migrates to another network. However, the migration of a mobile node often involves connectivity disruption due to bad wireless coverage, potential device overhead on the wireless interface to switch the wireless network to connect, and configuring a new IP address. The connectivity disruption can induce significant delay on the SCTP communications, because it causes retransmission time outs (RTOs) for lost packets that are transmitted in this period. In order to avoid the delay caused by the RTOs, this document describes a new retransmission trigger based on endpoint readdressing events. SCTP can minimize the delay caused by migration involving connectivity disruption with this retransmission trigger. "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, 19-Nov-07, 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. "Use Cases and signaling requirements for Point-to-Multipoint PW", Frederic JOUNAY, 20-Nov-07, This document provides some use cases advocating for the definition of a unidirectional Point-to-Multipoint Pseudowire (P2MP PW) and its relevant Virtual Private P2MP Service (VPMS). Based on these use cases it also presents a set of requirements for the set up and maintenance of P2MP PW, proposed as guidelines for possible solutions. "Considerations about Multicast for BGP/MPLS VPN Standardization", Thomas Morin, Ben Niven-Jenkins, Yuji Kamite, Raymond Zhang, Nicolai Leymann, 25-Feb-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. "SAVA Testbed and Experiences to Date", Jianping Wu, 13-Mar-08, Since the Internet uses destination-based packet forwarding, malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, we prototyped an implementation of the IP Source Address Validation Architecture (SAVA) and conducted the evaluation on an IPv6 network. This document reports our prototype implementation and the test results, as well as the lessons and insights gained from our experimentation. "Label Distribution Protocol Extensions for Half-Duplex Multipoint-to-Multipoint Label Switched Paths", Frank Brockners, Ijsbrand Wijnands, Ali Sajassi, 22-Feb-08, This document describes a mechanism to construct Label Switched Paths (LSP) over MPLS using an extended version of the Label Distribution Protocol (LDP) between a set of clients and servers. This communication mechanism has the capability that servers can communicate with other servers and clients, whereas clients can only communicate with servers but not with other clients. "Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP)", Michael Procter, 21-Feb-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. "Elimination of Proxy NDP from Home Agent Operations", Ryuji Wakikawa, Aramoto Masafumi, Pascal Thubert, 18-Nov-07, This document summarizes how to eliminate the Proxy NDP from the Home Agent's operations. Although the Proxy NDP is mainly used to intercept packets by a Home Agent on Mobile IPv6 and NEMO, it brings several limitations to the protocols. "Authentication Protocol for Mobile IPv6", Alpesh Patel, Kent Leung, Mohamed Khalil, Haseeb Akhtar, Kuntal Chowdhury, 4-Dec-07, 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, 12-Nov-07, 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. "Response Code for Indication of Terminated Dialog", Christer Holmberg, 21-Feb-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, normally a forking SIP proxy, to allow the UAC to know that an early dialog has been terminated before it a final response is sent to the request. "Diameter State Recovery Considerations", Tolga Asveren, Ulf Bodin, 11-Dec-07, This document discusses parameters to consider, different approaches and design strategies to synchronize and/or recover state in Diameter applications after failure of an active instance. "Sieve Email Filtering: Ihave Extension", Ned Freed, 23-Feb-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 satifies the needs of the script. "Sieve Email Filtering: Environment Extension", Ned Freed, 28-Mar-08, This document describes the "environment" extension to the Sieve email filtering language. The "environment" extension gives Sieve access to information about the environment where the Sieve interpreter is running. "A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU)", Jean-Pierre Evain, 13-Feb-08, This document describes a Uniform Resource Name (URN) namespace for the European Broadcasting Union (EBU) for naming persistent resources defined within EBU technical documentation and Internet resources. Example resources include technical documents and specifications, eXtensible Markup Language(XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the EBU. "Registration of Enumservices for experimental, private or trial use", Bernie Hoeneisen, 23-Oct-07, This document provides a guide to the creation of new IANA registrations of experimental, private or trial ENUM (E.164 Number Mapping) services. It is also to be used for updates of those experimental, private or trial Enumservice (X-Enumservice) registrations. "The DVB-RCS MIB", Stephane Combes, 3-Dec-07, This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS). It defines a set of MIB entities to characterise the behaviour and performance of network layer entities deploying DVB-RCS. "Reserved IPv6 Interface Identifiers", Suresh Krishnan, 6-Nov-07, 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. "GRE Key Option for Proxy Mobile IPv6", Ahmad Muhanna, Mohamed Khalil, Sri Gundavelli, Kent Leung, 10-Oct-07, The Proxy Mobile IPv6 base specification defined in [PMIP6-ID] allows the mobile node's IPv4 and IPv6 traffic between the local mobility anchor and the mobile access gateway to be tunneled using IPv6, IPv4 or IPv4-UDP encapsulation headers. These encapsulation modes do not offer semantics for the tunnel end-points to expose a service identifier that can be used to identify traffic for a certain classification, such as for supporting mobile nodes that are using overlapping private IPv4 addressing. The extensions defined in this document allow the mobile access gateway and the local mobility anchor to negotiate GRE encapsulation mode and along with the GRE symmetric key or asymmetric keys for marking the flows, so that differential processing can be applied by the tunnel peers over those flows. "A Registry for SMTP Enhanced Mail System Status Codes", Tony Hansen, John Klensin, 25-Feb-08, The specification for enhanced mail system enhanced status codes, RFC 3463, establishes a new code model and lists a collection of status codes. While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes. This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry. "Interdomain Presence Scaling Analysis for the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 16-Jan-08, This document analyzes the network impact of presence sharing between domains that federate using the Extensible Messaging and Presence Protocol (XMPP). "Extensible Supply-chain Discovery Service Concepts", Michael Young, 30-Oct-07, 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-02". 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, 22-Feb-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, 22-Feb-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, 24-Feb-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. "Alarms in SYSLOG", Rainer Gerhards, Sharon Chisholm, 13-Mar-08, This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. "The Session Initiation Protocol (SIP) P-Served-User Private-Header (P-Header)", Hans Erik van Elburg, 13-Dec-07, 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 to convey 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, 25-Feb-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 and should also serve as input to the ongoing discussions on reducing Spam for Internet Telephony (SPIT). "Password Extension for the TLS Client Authentication", Mohamad Badra, 23-Feb-08, This document specifies a new Transport Layer Security (TLS) extension and a new TLS message providing TLS client authentication using passwords. It provides client credential protection. "DNSSEC Trust Anchor History Service", Wouter Wijngaards, 12-Oct-07, When DNS validators have trusted keys, but have been offline for a longer period, key rollover will fail and they are stuck with stale trust anchors. History service allows validators to query for older DNSKEY RRsets and pick up the rollover trail where they left off. The service can be made to withstand multiple key compromises and large-scale spoofing. "Interactions between PMIPv6 and MIPv6: scenarios and related issues", Gerardo Giaretta, 16-Nov-07, The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) protocols interact with each other need special considerations. An analysis of all the scenarios that involve this interaction is necessary in order to provide guidelines to PMIPv6 protocol design and applicability. This document describes all identified possible scenarios, which require an interaction between PMIPv6 and MIPv6 and discusses all issues related to these scenarios. Solutions to enable these scenarios are also described. "Guidelines for Free Standards in the IETF", Simon Josefsson, 23-Oct-07, This document discuss copyright and patents in standard documents from a free software perspective. The document contains instructions for document authors who wish to encourage and enable free software implementations of their standard. It can also be used as a check- list for document reviewers and patent license reviewers. "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. "IPFIX Export per SCTP Stream", Benoit Claise, 25-Feb-08, This document specifies an improvement to the use of SCTP as specified in the IPFIX specifications in order to be able to deduce the data record loss per template record in case of partially-reliable SCTP export. This specification offers several extra advantages: immediate export of the template withdrawal message, immediate reuse of template ID within a stream, and the collecting process's job is easier. "A Session Initiation Protocol (SIP) Extension for the Identification of Services", Keith Drage, 12-Jul-07, 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 RFC 3840 [9] and RFC 3841 [10] to identify usage of both services and applications between end UAs. "DHCPv6 Based Home Network Prefix Delegation for PMIPv6", Behcet Sarikaya, Frank Xia, 9-Nov-07, In Proxy Mobile IPv6, one prefix can only be assigned to one interface of a mobile node by the local mobility anchor (LMA) and different mobile nodes can not share this home network prefix. Managing per-MN's interface home network prefixes is likely to increase the processing load at the LMA. Based on the idea that Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers can manage prefixes, we propose a new technique in which LMA offloads delegation and release tasks of the prefixes to the DHCPv6 server. LMA requests a prefix for an incoming mobile node to the DHCPv6 server. Based on this prefix, the mobile node can create a home address for its interface. When the mobile station leaves the network, the prefix is returned to the DHCPv6 server. Authentication, Authorization and Accounting (AAA) servers can also play a role in prefix delegation. "GMPLS Asymmetric Bandwidth Bidirectional LSPs", Lou Berger, Attila Takacs, Diego Caviglia, Don Fedyk, Julien Meuric, 12-Oct-07, This document defines a method for the support of GMPLS Asymmetric Bandwidth Bidirectional LSPs. The presented approach is applicable to any switching technology and builds on the original RSVP model for the transport of traffic related parameters.Contents "HTTP Cache Channels", Mark Nottingham, 15-Oct-07, This specification defines "cache channels" to propagate out-of-band events from HTTP origin servers (or their delegates) to subscribing caches. It also defines an event payload that gives finer-grained control over cache freshness. "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, 8-Nov-07, 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, 21-Dec-07, 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 . "Dynamic Host Configuration Protocol (DHCP) Option for a Location-by-Reference (LbyR) Uniform Resource Identifier (URI)", James Polk, 19-Nov-07, This document creates a Dynamic Host Configuration Protocol (DHCP) Option for the Location-by-Reference (LbyR) Uniform Resource Identifier (URI) of an endpoint. For example, an endpoint can be a Session Initiation Protocol (SIP) User Agent (i.e., a phone). This LbyR URI can be included in a UA's messages to inform other nodes of that entity's geographic location, once the URI is dereferenced by a Location Recipient. "An XCON Client Conference Control Package for the Media Control Channel Framework", Chris Boulton, Mary Barnes, 22-Feb-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, 25-Feb-08, Saratoga is a simple, lightweight, UDP-based transfer protocol. This is a companion document to the Saratoga specification, given in draft-wood-tsvwg-saratoga. This document describes how to use Saratoga as a Delay-Tolerant Networking (DTN) "convergence layer" with the DTN Bundle Protocol, and with DTN Bundle Agents. "Route Optimization for Proxy Mobile IPv6", Marco Liebsch, Long Le, Julien Abeille, 13-Nov-07, The IETF is specifying a protocol for network-based localized mobility management, which takes basic operation for registration, tunnel management and de-registration into account. This document specifies a protocol for route optimization in networks, which support network-based mobility management. The specified protocol focuses on efficient set up and maintenance of a route optimized path between two mobile nodes and suits complex mobility scenarios as well as networks with multiple mobility anchors. "802.1ah Ethernet Pseudowire", Luca Martini, Ali Sajassi, 22-Feb-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, 25-Feb-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. "Binding Revocation for IPv6 Mobility", Ahmad Muhanna, Mohamed Khalil, Sri Gundavelli, Kuntal Chowdhury, Parviz Yegani, 19-Nov-07, This document defines the revocation semantics for terminating a mobile node's mobility session. These semantics are generic enough and can be applied in both client-based and network-based mobility management protocols. "Performance Analysis of Inter-Domain Path Computation Methodologies", Sukrit Dasgupta, Jaudelice Oliveira, JP Vasseur, 7-Nov-07, 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 & Solutions", Marc Willekens, Miguel Garcia-Martin, Peili Xu, 25-Feb-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). Some methods already proposed and provided as ad-hoc solutions are indicated as background information. Furthermore, a clarification is made about a best common practice for the use of 'ptime/maxptime'. "Benchmarking Terminology for Wireless LAN Switching Systems", Tarunesh Ahuja, Tom Alexander, Scott Bradner, Sanjay Hooda, Jerry Perser, Muninder Sambi, 2-Jan-08, This document provides a terminology to be used when performing performance test and benchmarking of wireless LAN (WLAN) switches and controllers, including systems comprising groups of controllers and Access Points. The various wireless-specific device nomenclature, as well as the definitions of configuration parameters and test conditions that may be used to characterize the performance of these devices, are provided. The document also defines some of the metrics used during WLAN switch benchmarking. This terminology is to be used in conjunction with the companion methodology document. "Benchmarking Methodology for Wireless LAN Switching Systems", Tarunesh Ahuja, Tom Alexander, Scott Bradner, Sanjay Hooda, Jerry Perser, Muninder Sambi, 2-Jan-08, This document provides a framework and methodology for performing performance test and benchmarking of wireless LAN (WLAN) switches and controllers, including systems comprising groups of controllers and WTPs. This document defines and discusses a number of tests and associated test conditions that may be used to characterize the performance of such systems, and also supplies the methods used to calculate the expected results of these tests. Specific formats for reporting the results of the tests are also provided, where applicable. The tests described in this document extend the methodology defined for benchmarking network interconnect devices in RFC 2544, and LAN switches in RFC 2889, to WLAN switch controller systems. The methodology herein is to be used together with the companion terminology document. "Imprecise and alternative events for iCalendar and iTIP", Fábio Henrique Silva, Rik Drummond, 21-Dec-07, This document defines extensions to iCalendar and iTIP that allow the expression of imprecise and multiple alternative events in calendar objects and scheduling messages. Imprecise events can be used to imprecisely describe an event by specifying various ranked periods of time in which it could be scheduled. Alternative events can be used to describe an event in terms of multiple ranked event descriptions, imprecise or not, that could alternatively be scheduled. "Mobility Support in 6LoWPAN", Myung-Ki Shin, 13-Nov-07, This draft lists mobility scenarios and suggests solutions of how to provide mobility support in IPv6 Low-power Wireless Personal Area Metworks (6LoWPANs). "Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions", Vince Mammoliti, Carlos Pignataro, Peter Arberg, John Gibbons, Paul Howard, 4-Dec-07, This document describes a set of Layer 2 Tunneling Protocol (L2TP) Attribute Value Pair (AVP) extensions designed to carry the Access Line information which is not currently available by the existing L2TP AVP set. It is expected that this document will be updated if and when new line information is available, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", Thomas Schmidt, Matthias Waehlisch, 25-Feb-08, This document discusses current mobility extensions to IP layer multicast. Problems arising from mobile group communication in general, in the case of multicast listener mobility and for mobile Any Source Multicast as well as Source Specific Multicast senders are documented. 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 w.r.t. the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility. In addition to providing a comprehensive exploration of the mobile multicast problem and solution space, this document attempts to draft a conceptual roadmap for initial steps in standardization for the use of future mobile multicast protocol designers. "IPv6 Configuration in IKEv2", Pasi Eronen, 6-Feb-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, 8-Apr-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, 9-Jan-08, This document describes the Handle Resolution option for the ASAP protocol. "Media Resource Brokering", Chris Boulton, Roni Even, 6-Feb-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. "Evaluation of RFC 4138", Markku Kojo, Kazunori Yamamoto, Max Hata, Pasi Sarolahti, 19-Nov-07, Forward-RTO recovery (F-RTO) specified in RFC 4138 is an algorithm for detecting a spurious retransmission timeout with TCP and SCTP. This document describes the advantages of F-RTO and summarizes the experience in its implementations and the experiments conducted with it. By analyzing the implications of the spurious retransmission timeouts on the regular RTO recovery and Forward-RTO recovery algorithm, including a detailed corner case analysis, it shows that F-RTO does not have negative impact on the network when used with an appropriate response algorithm even in the rare cases where F-RTO falsely declares a retransmission timeout spurious. It concludes with a recommendation that F-RTO is to be advanced to the standards track. "Proxy Mobile IPv6 indication and discovery", Damjan Damic, Domagoj Premec, Basavaraj Patil, Meghana Sahasrabudhe, Suresh Krishnan, 25-Feb-08, Proxy Mobile IPv6 is a network-based mobility protocol that enabes mobility management for an IP host as it moves across different points of attachment within the mobility domain. An IP host whose mobility is being managed by the network is unaware of the access networks capability to do mobility management on its behalf using Proxy Mobile IPv6. This draft proposes mechanisms by which the host is informed of Proxy Mobile IPv6 support, as well as how to actively discover such capability in the network that host attaches to. The ability of the host to discover or be aware of Proxy Mobile IPv6 support in the access network enables better decision making in terms of the network selection and attach procedure as well as the choice of mobility management. "File Descriptions Extension to the Presence Information Data Format (PIDF)", Miguel Garcia-Martin, Marcin Matuszewski, 16-Nov-07, The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. Presentities publish their presence information, typically towards presence agents. PIDF has been extended to provide rich presence information, including, for example, the location of the presentity, their activities, mood, the capabilities of their user agents, etc. Presentities are willing to provide the description of available files at watcher's disposal. This might be the case for photographs taken with a mobile device, a recorded lecture audio file, etc. This document extends the PIDF to provide the syntax and format for the description of files within the PIDF. "A Session Initiation Protocol (SIP) Event Package and Data Format for Describing Files", Miguel Garcia-Martin, Marcin Matuszewski, 16-Nov-07, This document specifies the format and semantics associated to a 'file' event package that allows SIP endpoints to publish the availability of files. A file can be, for example, images, video files, audio files, etc. The event package reuses the eXtended Mark-up Language (XML) 'file-metadata' document to provide file descriptions. This event package also allows SIP endpoints to subscribe to changes in the availability of files, or perform searches for the availability and location of a given file. Support for partial notifications and publications is also accomplished by using XML patch operations. "Sharing Files with the Session Initiation Protocol (SIP)", Miguel Garcia-Martin, Marcin Matuszewski, Nicklas Beijar, Juuso Lehtinen, 16-Nov-07, This memo proposes a SIP framework used for advertising and searching for shared files within a given community. The memo defines the signaling that users to announce the availability of files stored in their User Agents (UA). It also provides the signaling for users to perform searches of available files and monitor changes in those files. Additionally, this memo describes the signaling used to access a file. These methods can be used in (but are not limited to) SIP peer-to-peer systems based on centralized, semi-centralized or fully distributed architectures. "NERD: A Not-so-novel EID to RLOC Database", Eliot Lear, 23-Jan-08, LISP is a protocol to encapsulate IP packets in order to allow end sites to multihome without injecting routes from one end of the Internet to another. This memo specifies a database and a method to transport the mapping of EIDs to RLOCs to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of of all EID/RLOC mappings scales well to at least 10^8 entries, and that use of DNS or any approach that queries for mappings has substantial operational concerns. "TLS using EAP Authentication", Yoav Nir, Hannes Tschofenig, Peter Gutmann, 4-Apr-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, 25-Feb-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, 30-Mar-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, 9-Jan-08, This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. "Allowing SIP Resource-Priority Header in SIP Responses", James Polk, 23-Feb-08, The Session Initiation Protocol (SIP) Resource-Priority Header is ignored in SIP responses, according to RFC 4412. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412's communications model by optionally allowing a SIP server or user agent (UA) to process the Resource-Priority Header in a response. "LIS to LIS Protocol Requirements", James Winterbottom, Steve Norreys, 19-Nov-07, This document describes requirements for a LIS to LIS protocol and provides examples of where such a protocol is applicable. "A Framework to tackle Spam and Unwanted Communication for Internet Telephony", Hannes Tschofenig, Henning Schulzrinne, Dan Wing, Jonathan Rosenberg, Daniel Schwartz, 25-Feb-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, for example, 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, 22-Feb-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, reputation systems of social networks or other extensions. "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. "Byte and Packet Congestion Notification", Bob Briscoe, 25-Feb-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 decode 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. "Extensible Peer Protocol (XPP)", Enrico Marocco, Emil Ivov, 16-Nov-07, This document defines the Extensible Peer Protocol (XPP), a lightweight binary protocol for end-to-end sessions between peers in distributed overlay networks. One of the main goals while creating this protocol was support for nodes located behind firewalls and NATs. XPP therefore uses UDP and allows endpoints to simultaneously initiate sessions. Given the choice of the underlying protocol (UDP), XPP also defines mechanisms for message fragmentation and reliability. "XPP Extensions for Implementing a Passive P2PSIP Overlay Network based on the CAN Distributed Hash Table", Enrico Marocco, Emil Ivov, 16-Nov-07, This document defines a set of extensions for the Extensible Peer Protocol (XPP) required for creating a P2PSIP overlay network based on the CAN distributed hash table algorithm. It specifies how peers and clients must behave in order to maintain the overlay and use it for the establishment of multimedia communication sessions. To limit the overhead due to maintenance operations and to allow the adoption of security policies for preventing malicious nodes to damage the overlay, joins are always initiated and controlled by existing peers (hence the passive in PCAN). "Security API for the IEEE 802.16 Security Sublayer", Pascal Urien, 18-Dec-07, This document describes a security Application Programming Interface (API), which aims at supporting tamper resistant devices that perform collaborative tasks with the IEEE 802.16 security sublayer. The security sublayer provides operators with strong protection from theft of service. This security API enables to transfer critical calculations or protocol processing to trusted computers, such as smart cards or trusted platform modules (TPMs). "Commissioning in 6LoWPAN", Ki-Hyung Kim, Chae-Seong Lim, Seung Yoo, Soohong Daniel Park, Geoffrey Mulligan, 10-Mar-08, The commisioning process defines the startup procedure taken by the 6LoWPAN device. This document defines the startup procedure that all kinds of devices must take to become part of the network. "Peering Data for NSIS Signaling Layer Protocols", Jukka Manner, Lauri Liuhto, Nuutti Varis, Teemu Huovila, 25-Feb-08, When an NSLP protocol initiates a signaling session and requests either reliable or secure transport (or both), NSLP data can not be carried within the GIST Query. Thus the NSLP at the responding node can not have NSLP specific information for peering decisions. Next generation NSLP protocols may need more information to be able to make right peering decisions. This draft presents a new Peering Information Object (PIO) for GIST intended to carry NSLP-specific peering data. "An Analysis of Do Not Disturb (DND) Implementations in the Session Initiation Protocol (SIP)", John Elwell, Srivatsa Srinivasan, 16-Nov-07, Do Not Disturb (DND) is a commonly used expression for indicating a condition where a human user of real-time communications does not wish to be interrupted by incoming calls or other forms of communication. This document discusses the nature of DND, ways of observing DND, and limitations of and possible improvements to DND support in the Session Initiation Protocol (SIP) and the Rich Presence Information Data Format (RPID). This work is being discussed on the bliss@ietf.org mailing list. "Guidelines for Using the Privacy Mechanism for SIP", Mayumi Munakata, Shida Schubert, Takumi Ohba, 27-Mar-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, 20-Feb-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, Jonathan Rosenberg, Salman Baset, Henning Schulzrinne, 24-Feb-08, This document defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) binary signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract hash table 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 data kinds 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, 17-Dec-07, 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. "Applicability Statement for SecureMail: A framework for increasing email security", Michael Pearson, Ferry Hendrikx, Matthew Hunt, 9-Jan-08, This document provides an Applicability Statement for Securemail, a framework proposal for secure transmission and better authentication of email based on current Internet standards. The SecureMail framework proposes the use of Transaction Layer Security (TLS), the Sender Policy Framework (SPF) and Sender ID to support secure email communication between internet servers with some assurance of the authenticity of the message sender. "HELD Protocol Context Management Extensions", James Winterbottom, Hannes Tschofenig, Martin Thomson, 19-Feb-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. "secure anycast tunneling protocol (SATP)", Othmar Gsenger, 23-Jan-08, The secure anycast tunneling protocol (SATP) defines a protocol used for communication between any combination of unicast and anycast tunnel endpoints. It allows tunneling of every ETHER TYPE protocol (ethernet, ip ...). SATP directly includes cryptography and message authentication based on the methodes used by SRTP. It can be used as an encrypted alternative to IP Encapsulation within IP [3] and Generic Routing Encapsulation (GRE) [4]. It supports both anycast receivers and senders. "Automated Bundle Agent Discovery for Delay/Disruption-Tolerant Networking", Jim Wyllie, Wesley Eddy, Joseph Ishac, Will Ivancic, Shawn Ostermann, 18-Nov-07, In Delay/Disruption-Tolerant Networking (DTN), Bundle Agents form an overlay network that forwards DTN bundles between their source and destination applications. This document describes a mechanism that Bundle Agents can use to discover when they are in contact with one another and optionally provide information on the additional properties of current or future contacts, such as duration and capabilities. This information can be used to trigger bundle forwarding or make future bundle scheduling decisions. "Reference Model for IPFIX Mediators", Atsushi Kobayashi, Keisuke Ishibashi, Kondoh Tsuyoshi, Daisuke Matsubara, 25-Feb-08, An IPFIX Mediator is an intermediate device between IPFIX Exporting Processes and IPFIX Collecting Processes. IPFIX Mediators act as an IPFIX Proxy, and IPFIX Concentrator. IPFIX Mediators mediate IPFIX protocol using several functions. That enables the flow-based measurement system to become a high-capacity system and accommodate a variety of monitoring methods. This document describes each function that is provided by IPFIX Mediators and the method of handling the Flow Records of each function. In addition, this document describes a model of an applicable scenario using IPFIX Mediators. "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks", Greg Bernstein, 20-Feb-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. "Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests", Robert Sparks, 7-Feb-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. "Changes to the Internet Standards Process defined by RFC 2026", Brian Carpenter, 16-Jan-08, This document defines a number of changes to RFC 2026, the basic definition of the IETF standards process. While some of them are definite changes to the rules, the intention is to preserve the main intent of the original rules, while adapting them to experience and current practice. "Multiple Reply to MESSAGE requests in the Session Initiation Protocol (SIP)", Qian Sun, Linyi Tian, Daqi Ren, 11-Oct-07, This document defines a multiple target address extension to the Reply-To header field for the SIP MESSAGE method. The extension includes the use of a pointer to a Uniform Resource Identifier (URI)- list in the Reply-To header field. "DKIM Third-Party Authorization for Sender Signer Practices", Douglas Otis, 18-Mar-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. "Flushing Mechanism for Routing Optimization in PMIPv6", Jaehwoon Lee, Gyungchul Sihn, Hyunseo Park, Sanghyun Ahn, Younghan Kim, 17-Feb-08, In order to solve the inefficient route problem of PMIPv6, a mechanism to optimize the route between two mobile nodes within the same PMIPv6 domain has been proposed. However, this route optimization mechanism may result in the out-of-order packet delivery problem. In this draft, we propose a mechanism that can resolve the out-of- order packet delivery problem by introducing the Flush message that notifies the change of the tunnel endpoint and allows the in-order delivery of packets even in the case of the route optimization. "Diameter Proxy Mobile IPv6: Support For Mobility Access Gateway and Local Mobility Anchor to Diameter Server Interaction", Jouni Korhonen, Julien Bournelle, Ahmad Muhanna, Kuntal Chowdhury, Ulrike Meyer, 25-Feb-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. The access authentication procedure of the Proxy Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario bootstrapping. Rather than defining a completely new set of attributes or a new Diameter application this specification leverages the work that has already been done for the Mobile IPv6 bootstrapping. "Mobile IP Interactive Connectivity Establishment (M-ICE)", Hannes Tschofenig, 25-Feb-08, This document describes how the Interactive Connectivity Establishment (ICE) methodology can be used for Mobile IP to determine whether end-to-end communication is possible. ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol in addition to mechanisms for checking connectivity between peers. After running the ICE the two MIP end points will be able to communicate directly or through a relay via Network Address Translators (NATs), Network Address and Port Translators (NAPTs) and firewalls. This document addresses also the problems raised in RFC 4487 "Mobile IPv6 and Firewalls: Problem Statement". "RadSec Version 2 - A Secure and Reliable Transport for the RADIUS Protocol", Stefan Winter, Mike McCauley, Stig Venaas, 7-Feb-08, This document describes implementations of a reliable transport (TCP) and security on the transport layer (TLS) for the RADIUS protocol [2]. This enables dynamic trust relationships between RADIUS servers. "Delay Tolerant Networking TCP Convergence Layer Protocol", Michael Demmer, Jörg Ott, 25-Feb-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, 17-Dec-07, 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, 7-Nov-07, 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. This document describes the usage of multiple Synchronization VECtors (SVECs) in the SVEC list. When a PCE computes multiple sets of dependent path computation requests concurrently, it is required to use SVEC list for association among the sets of dependent path computation requests. The aim of this document is to define the association among SVECs and its processing rule. "Extensions to GMPLS RSVP-TE for Bidirectional Lightpath with the Same Wavelength", Sugang Xu, Hiroaki Harai, Daniel King, 12-Nov-07, For bidirectional lightpaths provisioning, in the case of optical nodes that do not support wavelength conversion, it would be necessary to use the same wavelength along the route on each direction. In certain optical network scenarios, the use of the same wavelength on both directions would be advantageous. For instance, some ROADMs may add/drop the same wavelength simultaneously. In other cases, the users' optical end nodes are equipped with fixed-wavelength transponders. This document describes extensions to RSVP-TE signaling for bidirectional wavelength lightpaths that require the same wavelength on both directions. By using an LSP_ATTRIBUTES object defined in [RFC4420], the extensions enable the new type lightpaths to support the low cost configuration at users' optical end nodes. "RADIUS Support for EAP Re-authentication Protocol", Kedar Gaonkar, Lakshminath Dondeti, Vidya Narayanan, Glenn Zorn, 25-Feb-08, RFCxxxx (draft-ietf-hokey-erx after publication) [6] specifies the EAP Re-authentication Protocol (ERP). This document specifies RADIUS support for ERP. The procedures in RFC3579 [1] are used for encapsulating the EAP Initiate and Finish messages specified in RFCxxxx (draft-ietf-hokey-erx after publication) [6]. This document specifies attributes for the request and delivery of Domain Specific Root Keys from the AAA/EAP server to the ER Server. Additionally, this document also specifies RADIUS message processing rules relevant to ERP. "Multicast Forwarding Equivalence Class [MFEC]", Feng Guo, 27-Dec-07, At present, the multimedia services such as IPTV are gaining importance. Multicast technologies play an inevitable role in these multimedia services. The main factors affecting the multicast technologies are the convergence speed and the capacity of the multicast routing table. One of the easiest and the most commonly practiced methods in nowadays multicast deployment is to push the data to the end router by static configurations (igmp static group). This will reduce the delay in channel switching. The data flow of multiple channels from one or several servers are transmitted along the distribution tree. The distribution tree for multiple channels may be composed of only one same distribution tree. A router, however, maintains separate protocol-status and provides separate protocol-packets content for each channel. This prolongs the route convergence, increases the status-space and reduces the exchange rate of protocol-packets. This document proposes a solution to speed up the route convergence, reduce the states in the multicast forwarding table and increase the exchange rate of packets. This can be achieved by using the same state for the data flows that passes the same path in the distribution tree. This same state is called Multicast Forwarding Equivalent Class (MFEC). In other words, MFEC is a group of multicast packets that are forwarded over the same path with the same traffic handling treatment. This solution extends various multicast protocols such as PIM- SSM, PIM-SM, Bidir-PIM, PIM-DM and DVMRP, and perfects application of multicast. "Simple Authentication Schemes for the ALC and NORM Protocols", Vincent Roca, 19-Nov-07, 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. "MIPv4 Authentication Performance Using RADIUS and Diameter MIPv4", Ahmad Muhanna, Mohamed Khalil, Avi Lior, 19-Nov-07, 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. This document 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. "ACL data model for NETCONF", Iijima Tomoyuki, Yoshifumi Atarashi, Hiroyasu Kimura, Makoto Kitani, Hideki Okita, 26-Dec-07, Data models are to be discussed within the NETCONF framework shortly. We devised data model of ACL(Access Control List) and moreover developed a network configuration application using the data model. This document introduces the data model which we developed so that it facilitates discussion of data model which NETCONF protocol carry. "Three State PCN Marking", Jozef Babiarz, Xiao-Gao Liu, Kwok Ho Chan, Michael Menth, 18-Nov-07, This document proposes a mechanism for admission control and flow termination. It is based on the concept of pre-congestion notification (PCN) using three different codepoints: "no pre- congestion", "admission-stop", and "excess-traffic" for packet marking. Therefore, the proposal is called three state marking (3sm). The behaviour of edge nodes is presented which distinguishes from other proposals through little complexity and its ability to cope with multipath routing. Algorithms required for packet metering and marking are explained in detail. "Extensions for Multi-MTU Subnets", Iljitsch van Beijnum, 24-Feb-08, In the early days of the internet, many different link types with many different maximum packet sizes were in use. For point-to-point or point-to-multipoint links, there are still some other link types (PPP, ATM, Packet over SONET), but shared subnets are now almost exclusively implemented as ethernets. Even though the relevant standards mandate a 1500 byte maximum packet size for ethernet, more and more ethernet equipment is capable of handling packets bigger than 1500 bytes. However, since this capability isn't standardized, it's seldom used today, despite the potential performance benefits of using larger packets. This document specifies a mechanism for advertising a non-standard maximum packet size on a subnet. It also specifies optional mechanisms to negotiate per-neighbor maximum packet sizes so that nodes on a shared subnet may use the maximum mutually supported packet size between them without being limited by nodes with smaller maximum sizes on the same subnet. "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)", Lou Berger, Dimitri Papadimitriou, Don Fedyk, 25-Feb-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.Contents "Support for RSVP in Layer 3 VPNs", Bruce Davie, Francois Le Faucheur, Ashok Narayanan, 25-Feb-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. "SIV Authenticated Encryption using AES", Dan Harkins, 25-Feb-08, This memo describes SIV, a block cipher mode of operation. SIV takes a key, a plaintext, and multiple variable-length octet strings which will be authenticated but not encrypted. It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector. Depending on how it is used, SIV achieves either the goal of deterministic authenticated-encryption or the goal of nonce-based, misuse-resistant authenticated-encryption. "Comments on the Usefulness of Simple Best-Effort Traffic", Sally Floyd, 29-Jan-08, This document presents some observations on "simple best-effort" traffic, defined loosely for the purposes of this document as Internet traffic that is not covered by Quality of Service mechanisms, congestion-based pricing, cost-based fairness, admissions control, or the like. One observation is that simple best-effort traffic serves a useful role in the Internet, and is worth keeping. While differential treatment of traffic can clearly be useful, we believe such mechanisms are useful as **adjuncts** to simple best- effort traffic, not as **replacements** of simple best-effort traffic. A second observation is that for simple best-effort traffic, some form of rough flow rate fairness is a useful goal for resource allocation, where "flow rate fairness" is defined by the goal of equal flow rates for different flows over the same path. "Group Domain of Interpretation (GDOI) support for RSVP", Brian Weis, 22-Feb-08, This memo describes the policy required for the Group Domain of Interpretation (GDOI) group key management system to distribute security policy for RSVP. "Generalized Labels of Lambda-Switching Capable Label Switching Routers (LSR)", Tomohiro Otani, Hongxiang Guo, Keiji Miyazaki, Diego Caviglia, Zafar Ali, 25-Feb-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. "Emulating Border Flow Policing using Re-ECN on Bulk Data", Bob Briscoe, 25-Feb-08, Scaling per flow admission control to the Internet is a hard problem. A recently proposed approach combines Diffserv and pre-congestion notification (PCN) to provide a service slightly better than Intserv controlled load. It scales to networks of any size, but only if domains trust each other to comply with admission control and rate policing. This memo claims to solve this trust problem without losing scalability. It describes bulk border policing that provides a sufficient emulation of per-flow policing with the help of another recently proposed extension to ECN, involving re-echoing ECN feedback (re-ECN). With only passive bulk measurements at borders, sanctions can be applied against cheating networks. "RADIUS Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya, Jouni Korhonen, Sri Gundavelli, 25-Feb-08, Proxy Mobile IPv6 (PMIPv6) is network based mobility management protocol which allows IP session continuity for a mobile node (MN) without its involvement in mobility management. A mobile access gateway (MAG) is authorized to send Mobile IPv6 signaling messages on behalf of mobile nodes. The MAG requires a local mobility anchor address (LMAA), mobile node's identifier (MN-Identifier),and IPSec security association (SA) with it's LMA before it sends signaling messages. Interworking with existing authentication, authorization and accounting (AAA) infrastructure, MAG acquires the LMAA (directly or indirectly) and MN-Identifier. Local mobility anchor (LMA) also uses AAA infrastructure to authenticate MAG and build SA between MAG when IKEv2 IPSec is used for security between MAG and LMA . This document defines new RADIUS attributes and reasonably reuses existing attributes to serve the purpose. This information exchange takes place as part of the initial network access authentication procedure. Address configuration modes and others can also be obtained from AAA infrastructure to emulate MN's home link on access links. "Session Initiation Protocol (SIP) INFO Method Use", Eric Burger, 18-Nov-07, The purpose of the INFO request for the Session Initiation Protocol (SIP), as described by RFC 2976, is to provide mid-session SIP User Agent (UA)-to-SIP UA application data transport. In the years since the introduction of the INFO request, experience with the use of the INFO request indicates a number of problems. This document explains why there are INFO-based, proprietary protocols in the wild; the flaws of using INFO; and explains why it is not possible to create a framework to rescue INFO for general purpose use. Since SIP has evolved considerably since the introduction of INFO, this document highlights some of the new, robust mechanisms for achieving the work that previously led people to use INFO. As these mechanisms are now available, this document formally deprecates the use of INFO for new usages beyond the existing standardized ones, namely RFC 3372 (SIP-T) and RFC 4497 (QSIG). "LDP End-of-LIB", Rajiv Asati, 19-Nov-07, There are situations following LDP session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. These include session establishment when LDP-IGP sync is in use and session re-establishment following loss of an LDP session when LDP graceful restart is in use. 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. "Home Automation Routing Requirement in Low Power and Lossy Networks", JP Vasseur, 12-Nov-07, This document presents the home control and automation application specific requirements for Routing in Low power and Lossy Networks (RL2N). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include lighting control modules, heating control panels, light sensors, temperature sensors, gas/water leak detector, motion detectors, video surveillance, healthcare systems and advanced remote controls. Because such devices only cover a limited radio range, multi-hop routing is often required. Such devices are usually highly constrained in terms of resources such as battery and memory and operate in unstable environments. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home network environment. "Overview of Existing Routing Protocols for Low Power and Lossy Networks", JP Vasseur, 19-Nov-07, 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. Such low power and lossy networks (L2Ns) have routing 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 L2Ns. It provides guidance on how lessons from existing and prior efforts can be leveraged in future protocol design. "Future-Proof TLV Codepoint Space for LSP Ping", Adrian Farrel, George Swallow, 17-Nov-07, Techniques for detecting Multi-Protocol Label Switched (MPLS) data plane failures are described in RFC 4379 and include the definition of a control protocol for testing and verifying Label Switched Path (LSP) connectivity that is known as LSP Ping. The protocol consists of a set of messages each of which contains data encoded as TLVs. The LSP Ping protocol is being extended for several related uses. Each extension gives rise to the definition of new TLVs to be carried on the existing protocol messages. The LSP Ping specification makes it mandatory that all TLVs are understood by each participating Label Switching Router (LSR) that receives an LSP Ping message. This makes future extensibility hard without upgrading all LSRs in the network. This document defines ranges in the TLV codepoint space so that TLVs may be associated with different processing rules within an LSR if the TLV is unknown. This will make extensibility more simple. "Applicability Issues for IPsec NAT-Traversal in NAT-PT", Sangdo Lee, Sangjin Jeong, Hyoung-Jun Kim, 18-Nov-07, This memo describes how to apply IPsec protocol based on NAT- Traversal mechanisms and applicability issues at NAT-PT. "Loop-Free IP Fast Reroute Using Local and Remote LFAPs", Ibrahim Hokelek, 26-Feb-08, This draft describes a new loop-free IP fast reroute mechanism which enhances the IP Fast-ReRoute (IPFRR) [1,15] by introducing the concept of pre-computed remote Loop-Free Alternate Paths (rLFAPs) on top of the IPFRR local LFAP. In rLFAP, a router which is adjacent to the failed resource switches over to pre-computed LFAPs, if they exist, immediately after failure detection. Multi-hop neighbors (MNBs) are notified about this remote failure as quickly as possible using fast failure notification mechanism. Upon receipt of failure information, MNBs activate their pre-computed remote LFAPs that they maintain for protecting against remote failures within their multi-hop neighborhoods. In the worst case, where IPFRR results in forming micro-loops, rLFAP completely prevents micro-loops for single link failures and quickly converges to a loop-free path in case of multiple link failures. "LISP-CONS: A Content distribution Overlay Network Service for LISP", Scott Brim, 14-Nov-07, The Content distribution Overlay Network Service for LISP (LISP-CONS) is a protocol for distributing identifier-to-locator mappings for the Locator/ID Separation Protocol (LISP). LISP-CONS is not a routing protocol. LISP-CONS is designed to scale by using a hierarchical content distribution system comprised of Tunnel Routers, Content Access Resources, and Content Distribution Resources. "IANA Ethernet Considerations", Donald Eastlake 3rd, 21-Dec-07, Some IETF protocols make use of Ethernet frame formats and parameters. This document specifies IANA considerations for code points under the IANA OUI (Organizationally Unique Identifier). It also lists and discusses other Ethernet parameters related to IETF protocols. "Diameter Claissifier", Avi Lior, Mark Jones, 25-Feb-08, Many Diameter applications require to classify packets. Diameter base protocols provides an IP Filter Rule type and a QoS Filter Rule type that is being used to classify packets. However, because these types were defined for specific uses and defined in ways that are hard to extend and therefore are not generally applicable for those applications that require packet classifiers. This document describes a set of Diameter types that are useful to create packet classifiers. The packet classier type can be used by various applications to express packet classifiers that best match the application's specific needs. "SIP Identity using Media Path", Dan Wing, Hadriel Kaplan, 23-Feb-08, This document defines a new SIP identity mechanism which operates through SBCs and B2BUAs. This new identity mechanism creates a signature over certain SIP headers and certain SDP lines. When the SIP body contains SDP, both the SIP signaling path and the media path are used to perform the identity function; when the SIP body contains non-SDP body parts, they are signed in their entirety. "Mechanism for performing LSP-Ping over MPLS tunnels", Nitin Bahadur, 19-Nov-07, This document describes methods for performing lsp-ping traceroute over mpls tunnels. The techniques outlined in RFC 4379 fail to perform correct traceroute validation and path discovery for a LSP that goes over other mpls tunnels. This document describes new procedures that can be used in conjunction with the standard procedures described in RFC 4379 to trace such LSPs. "IPv4 Mobility extension for Multicast and Broadcast Packets", Samita Chakrabarti, Ahmad Muhanna, Gabriel Montenegro, Alexander Bachmutsky, Yingzhe Wu, Basavaraj Patil, Parviz Yegani, 18-Nov-07, The IP Mobility Protocol [RFC3344] describes multicast and broadcast packet transmission between the mobile node and the home network or visited network. Reverse Tunneling for Mobile IP [RFC3024] includes support for reverse tunneling of multicast and broadcast packets to the home network using the encapsulating delivery style between mobile nodes and the foreign agent. However, [RFC3024] says that once the encapsulated delivery style is negotiated, all packets must be encapsulated. In particular, this imposition prevents direct delivery of unicast packets. This causes tunnel overhead in the (typically) wireless medium between the mobile and the foreign agent. This document removes this imposition It also provides alternatives of direct delivery of multicast-broadcast packets between a foreign agent and a mobile node if allowed by the underlying link-layer. "Head Node Protection Extensions to RSVP-TE for LSP Tunnels", Wei Cao, Mach Chen, 17-Nov-07, Protection methods for RSVP-TE P2MP LSP have been described in [TE- FRR]([RFC4090]) and [P2MP-TE-Bypass], but there are no solutions to protect an RSVP-TE P2MP head node. This document discusses the scenario for RSVP-TE P2MP LSP head node failure protection and describes the protection procedures. RSVP-TE extensions for such protection are also described. To protect the head node, a backup head node is appointed which forwards traffic to downstream LSRs of the LSP when the protected head node fails. The backup head node is not on the path of protected LSP. Similar to [TE-FRR] there are two methods that can apply: one- to-one backup and facility backup. Only one-to-one backup is described in detail here, facility backup will be discussed in a future version of this draft. "A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP)", Atle Monrad, Salvatore Loreto, 19-Nov-07, This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the 3rd Generation Partnership Project (3GPP). 3GPP defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the 3GPP Support Team. "Flow selection Techniques", Lorenzo Peluso, 20-Nov-07, Flow selection is the process in charge of electing a limited number of flows from all of those observed at an observation point to be considered into the measurement process chain. The flow selection process can be enabled at different stages of the monitoring reference model. It can be performed at metering time once the packet classification has been executed, i.e. flow state dependent packet sampling, or at recording/exporting time by limiting the number of flows to be stored and/or exported to the collector applications. This document illustrates the motivations which might lead flow selection to be performed and presents a classification of the related techniques. The document furthermore provides the basis for the definition of information models for configuring flow selection techniques and discusses what information about the flow selection process is beneficial to be exported by adopting a suitable information model. "VPLS Extensions for Provider Backbone Bridging", Florin Balus, 27-Feb-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. "APT: A Practical Transit Mapping Service", Dan Jen, Michael Meisel, Dan Massey, Lan Wang, Beichuan Zhang, Lixia Zhang, 19-Nov-07, The size of the global routing table is a rapidly growing problem. Several solutions have been proposed. These solutions commonly divide the Internet into two address spaces, one for determining the delivery location, and one to use during transit. Packets destined for delivery addresses are tunneled through the default-free zone (DFZ), which uses only transit addresses. For this process to work, there must be a mapping service that can supply an appropriate destination transit address for any given delivery address. We present a design for such a mapping service. We adhere to a "do no harm" design philosophy: maintain all desirable features of the current architecture without negatively affecting its security or reliability. Our design aims to minimize delay and prevent loss in packet encapsulation, minimize the number of modifications to existing hardware, minimize the number of new devices, and keep the level of control traffic manageable. "Scaling Requirements for Presence in SIP/SIMPLE", Avshalom Houri, Sriram Parameswar, Edwin Aoki, Vishal Singh, Henning Schulzrinne, 18-Nov-07, The document provides a set of requirements for enabling interdomain scaling in presence for SIP/SIMPLE. The requirements are based on a separate scaling analysis document. "Utilizing HIP (Host Identity Protocol) for P2PSIP (Peer-to-peer Session Initiation Protocol)", Jani Hautakorpi, Gonzalo Camarillo, Joakim Koskela, 19-Nov-07, This document specifies how Host Identity Protocol (HIP) can be utilized in Peer-to-Peer Session Initiation Protocol (P2PSIP) networks. Peers in a P2PSIP network need to have long-lived connections to other peers in the network, and HIP can be utilized to setup and maintain those connections. HIP is a good choice for connection maintenance, because it provides functionalities like Network Address Translation (NAT) traversal, mobility, multi-homing, and enhanced security properties. "Fast Handovers for PMIPv6", Hidetoshi Yokota, Kuntal Chowdhury, Rajeev Koodli, Basavaraj Patil, Frank Xia, 25-Feb-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. "Security Requirements for the Geopriv Location System", Richard Barnes, Matt Lepinski, Hannes Tschofenig, Henning Schulzrinne, 25-Feb-08, Internet protocols that deal with presence-based location objects support a wide variety of applications. However, the dissemination of location objects from sources of location to consumers is a common feature of all location-based applications. In order to enable the development of broadly-applicable security and privacy mechanisms for dissemination of location objects, this document describes an end-to- end architecture for policy-constrained location distribution. In this architecture, location distribution is accomplished by a set of distributed actors. We describe the assurances that these actors require from the architecture, and derive more a more detailed description of the security features required to provide those assurances. "Fraud mitigation for IP-based emergency calling", Richard Barnes, Matt Lepinski, 22-Oct-07, The use of Internet technologies for emergency calling creates opportunities for fraud, relative to traditional circuit-switched emergency calling. This document describes the context for IP-based emergency calling, and the types of fraud which are possible within the system. A mitigation strategy for fraud against voice service providers is described; techniques for detecting or preventing other types of fraud will be incorporated in this document as they are available. "Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA) based Robot Challenges for SIP", Hannes Tschofenig, Eva Leppanen, Saverio Niccolini, Mayutan Arumaithurai, 25-Feb-08, A common approach to deal with unwanted communication attempts is to rely on some form of authorization policies, typically whitelists. In order to populate the entries in such an access control list it is helpful to have a way to challenge the entity willing to engage in a conversation (unless they are already pre-authorized). One reason why this is desired is to deal with robots that are aggressively distributing messages. This document describes how "Completely Automated Public Turing Test to Tell Computers and Humans Apart" (CAPTCHA) tests, which require human interaction, are applied to SIP. "Normative Language and References", Jon Peterson, 8-Nov-07, This document explores the use of normative language and references with a focus on reducing unnecessary normative references in IETF specifications. "Pre-Congestion Notification Encoding Comparison", Kwok Ho Chan, Georgios Karagiannis, T Moncaster, Michael Menth, Philip Eardley, Bob Briscoe, 25-Feb-08, A number of mechanisms have been proposed to support differential Qualiy of Service for packets in the Internet. DiffServ is an example of such a mechanism. However, the level of assurance that can be provided with DiffServ without substantial over-provisioning is limited. Pre-Congestion Notification (PCN) uses path congestion information across a PCN region to enable per-flow admission control to provide the required service guarantees for the admitted traffic. While admission control will protect the QoS under normal operating conditions, an additional flow termination mechanism is necessary to cope with extreme events (e.g. route changes due to link or node failure). In order to allow the PCN mechanisms to work it is necessary for IP packets to be able to carry the pre-congestion information to the PCN egress nodes. This document explores different ways in which this information can be encoded into IP packets. This document does not choose the encoding but provide guidance and recommendation based on different criteria. "One-way Passive Measurement of End-to-End Quality", Yutaka Kikuchi, Satoru Matsushima, Kenichi Nagami, Satoshi Uda, Nobuo Ogashiwa, 19-Nov-07, This draft describes a passive measurement method for one-way end-to- end quality. This method reports both whether a flow of tunnel packets is in-sequence or not and error types on detecting out-of- sequence. The method consumes a small resources therefore it can be adapted to many protocols that have sequence number field. "Peer-to-Peer Protocol (P2PP)", Salman Baset, Henning Schulzrinne, Marcin Matuszewski, 19-Nov-07, This document defines the Peer-to-Peer Protocol (P2PP), an application-layer binary protocol, for creating and maintaining an overlay of participant nodes. The overlay can be created using various structured and unstructured peer-to-peer protocols such as Bamboo, Chord, Pastry, Kademlia, Gnutella, and Gia. P2PP uses a secure transport, supports an application API, has mechanisms for NAT and firewall traversal, exchanging node capabilities, and diagnostic information. P2PP is designed to support a P2P Session Initiation Protocol (SIP) network, but it can be used for other applications as well. "MIPv6 Extensions for Mobile Multicast: Problem Statement", Hong-Ke Zhang, 20-Nov-07, Mobile multicast is a research hotspot and gets more and more study recently. But the current existent mobility management specifications can not provide effective multicast transmission. In this memo, we discuss the problems arising from mobile multicast and address the solutions space of mobility support specifications extensions to support mobile multicast services. "MANET_ID TLV", Ian Chakeres, 2-Feb-08, This document defines a message TLV named MANET_ID. The MANET_ID TLV is used by a (DYMO) process to identify information as belonging to a particular (DYMO) instance. This specification enables multiple instances of (DYMO) to run independently on the same node over the same interfaces. "Requirements for configuring Cryptographically Generated Addresses (CGA) and overview on RA and DHCPv6-based approaches", Sheng Jiang, 7-Jan-08, This document analyzes the requirements for the configuration Cryptographically Generated Addresses (CGA, [CGA]) and Multi-key CGAs [MCGA]. The applicability of Router Advertisement and DHCPv6 for this configuration is also discussed. "Six/One: A Solution for Routing and Addressing in IPv6", Christian Vogt, 19-Nov-07, There is heightened concern about the growth of the global routing table and the increased frequency of routing table updates. Both is due to the use of provider-independent addressing space in edge networks, which accommodates operators' desire to move traffic quickly and easily from one provider to another. The main recent proposals attempt to solve this problem by hiding provider- independent addressing space through a level of indirection. Unfortunately, indirection requires a non-trivial distribution of address translation information across the Internet. This is either slow, or costly in terms of signaling overhead, or both. Security and transitionability are further issues. This document proposes an alternative solution, which is based on a single, provider-dependent addressing space and hence avoids the problems of indirection. The solution meets the objectives of edge network operators while limiting the size of the routing table and its update frequency. "An Evaluation Framework for Data Modeling Languages in Network Management Domain", Hui Xu, Debao Xiao, 22-Jan-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. "Consumer Electronics Requirements for Network Mobility Route Optimization", Chan-Wah Ng, Jun Hirano, Alexandru Petrescu, Eun Paik, 16-Feb-08, This document illustrates different deployments of Network Mobility (NEMO) from the consumer electronics perspective. From these deployments, a set of requirements is deduced for Route Optimization (RO) with NEMO. "Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions", Minpeng Qi, 15-Nov-07, 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. "A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB)", Alexander Adolf, 18-Dec-07, This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB. "PKI Resource Query Protocol (PRQP)", Massimiliano Pala, 25-Feb-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. "An Internet Transition Plan", John Curran, 30-Jan-08, This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model. "Ivip (Internet Vastly Improved Plumbing) Architecture", Robin Whittle, 14-Jan-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. "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. "Representing metric values in MANETs", Justin Dean, 11-Mar-08, This document defines TLVs (type-length-value) structures for representing cost values using the generalized MANET packet/message format. A message block TLV structure is defined for representing a cost value associated with the local node. An address block TLV structure is defined for representing a cost value associated with links or a cost value associated with other nodes. Both TLV structures are defined for use within MANET protocols. Registry space is created for TLVs which follow this format. "The Hypertext Transfer Protocol (HTTP) GET-Location header", Julian Reschke, 4-Apr-08, Several hypertext transfer protocol (HTTP) extensions use methods other than GET to expose information. This has the drawback that this kind of information is harder to identify (missing a URL to which a GET request could be applied) and to cache. This document specifies a simple extension header through which a server can advertise a substitute URL that an HTTP client subsequently can use with the GET method. "Routing and Addressing Problem Statement", Thomas Narten, 11-Oct-07, There has been much discussion over the last years about the overall scalability of the Internet routing system. This document attempts to describe what the actual problem is and the various demands being placed on the routing system that have made finding a straightforward solution difficult. Comments should be sent to rrg@psg.com or to radir@ietf.org. "Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance Networks", Murali Sridharan, Kun Tan, Deepak Bansal, Dave Thaler, 29-Oct-07, 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, gracefully reduces the sending rate. "CAPWAP Protocol Binding MIB for IEEE 802.11", Yang Shi, Chris Elliott, 12-Feb-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. "CAPWAP Protocol Base MIB", Yang Shi, Chris Elliott, 12-Feb-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. "Delay-Tolerant Networking Metadata Extension Block", Susan Symington, 8-Feb-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. "MicroID", Jeremie Miller, Peter Saint-Andre, Fred Stutzman, 11-Dec-07, This specification defines MicroID, a lightweight identity technology that enables the creation of a portable identity token based on any two Uniform Resource Identifiers. "Hypertext Transfer Protocol (HTTP) Digest Authentication using Global System for Mobile Communications (GSM) A3 and A8", Brett Wallis, 8-Feb-08, This memo specifies a one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication based on Global System for Mobile Communications (GSM) authentication and key generation functions A3 and A8. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The A3-A8 mechanism performs user authentication and session key distribution in GSM and Universal Mobile Telecommunications System (UMTS) networks. A3-A8 is a challenge-response based mechanism that uses symmetric cryptography. "Mobility using Proxy MIP and Mobike", Stephane Antoine, 14-Feb-08, The simultaneous use of Mobike and Mobile IPv4 has been proposed to provide secure connectivity and session continuity to roaming corporate users. Optimization of this solution have eliminated the tunneling overhead of Mobile IPv4 in the vpn tunnel by having a Foreign Agent co-located to the mobile vpn gateway. This document further proposes an interaction between Mobike and Proxy Mobile IP that simplifies implementation and deployment of the previous methods. The mobile vpn gateway is co-located to the Mobility Proxy Agent and each Access Point in the corporate network is equipped with Proxy Mobile IP. When moving outside the corporate network, the Mobile Node secure connectivity and session continuity is handled by Mobike. Proxy Mobile IP alone is used to handle mobility when the Mobile Node moves within the corporate network. This document introduces an interaction between Internet Key Exchange v2 and Proxy Mobile IP in which the Internet Key Exchange AUTH request triggers the Proxy Mobile IP registration request to the internal Home Agent. This interaction easily allows the Mobile Node's home address to be used as vpn Tunnel Inner Address. "Experiments on SPIT in the Commercial VoIP Services", Jaeduck Choi, 16-Nov-07, This document shows some experimental results on SPIT on commercial VoIP services, in which a SIP UA has not been secured by SIP security protocol such as TLS. Although many service providers have been applying the HTTP digest scheme to authenticate a SIP UA, they often do not apply SIP signaling protection against potential threats between the SIP UA and the SIP proxy. This cause vulnerabilities to the VoIP services like SPIT. The aim of this memo is to inform the service providers of SPIT threats by showing some experimental results of SPIT on current VoIP networks. "Heartbeat Mechanism for Proxy Mobile IPv6", Vijay Devarapalli, Heeseon Lim, Nishi Kant, Suresh Krishnan, 19-Feb-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. "Locating Mobility Servers", Gabor Bajko, 18-Nov-07, 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 Mobility Services. Mobility Services are used to assist an MN in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in [1]. "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Mobility Server (MoS) discovery", Gabor Bajko, Subir Das, 11-Feb-08, This document defines a number of Dynamic Host Configuration Protocol (DHCP-for-IPv4 and DHCP-for-IPv6) 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. These Mobility Services are used to assist an MN 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]. "Spam Score for SIP", Dan Wing, Saverio Niccolini, Martin Stiemerling, Hannes Tschofenig, 24-Feb-08, This document defines a mechanism for SIP proxies to communicate a spam score to downstream SIP proxies and to SIP user agents. This information can then be used as input to other decision making engines, for example, to provide alternate call routing or call handling. "Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices", Henning Schulzrinne, Stephen McCann, Gabor Bajko, Hannes Tschofenig, 25-Feb-08, The IETF emergency services architecture assumes that access to a network has already happened using the traditional network access authentication procedures or that no authentication for network access is needed (e.g., in case of public hotspots). 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. There are, however, cases where a device is not in possession of credentials for network access, does not have a VoIP provider, or where the credentials are available but became invalid due to various reasons (e.g., credit exhaustion, expired accounts, etc.). This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture. "Evaluation Considerations for IP Autoconfiguration Mechanisms in MANETs", Hassnaa Moustafa, Carlos Bernardos, Maria Calderon, 8-Apr-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, 24-Feb-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, 4-Apr-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. "Bulk Registration Revocation in Mobile IPv4", Acee Lindem, Anand Oswal, 12-Feb-08, This document describes an extension to Mobile IPv4 Registration Revocation (as described in RFC 3543) for a home or foreign agent to revoke mobile IP services for multiple bindings or visitors with a single registration revocation exchange. "Heartbeat Mechanism for Local Mobility Anchors in Proxy Mobile IPv6", Jong-Hyouk Lee, 4-Mar-08, Proxy Mobile IPv6 (PMIPv6) introduces new mobility entities: the local mobility anchor (LMA) and the mobile access gateway (MAG). The LMA and MAG manage bi-directional tunnels between themselves to provide a network-based mobility service to mobile nodes (MNs) within a Proxy Mobile IPv6 Domain (PMIPv6-Domain). The failure of LMA connected with its MAGs causes the communication failure of MNs attached to the MAGs. Thus, the early failure detection of LMA is desirable for appropriate countermeasures. This document specifies a heartbeat mechanism for LMAs to detect the current reachability between the LMAs. "Sieve Notification Mechanism: SIP MESSAGE", Alexey Melnikov, Henning Schulzrinne, Qian Sun, 18-Feb-08, This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the SIP MESSAGE. "Reclassifying 240/4 as usable unicast address space", Vince Fuller, 25-Mar-08, This memo reclassifies the address block 240.0.0.0/4 as usable address space. While the community has not concluded whether the block should be considered public or private, given the current consumption rate, it is clear that the block should not be left unused. This document also makes several recommendations on ways that current implementations of the IP protocol stack will need to be modified to make this address space usable. "OSPF Multi-Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 14-Feb-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. "IPv6 Subnet Model", Hemant Singh, Wes Beebee, Erik Nordmark, 25-Feb-08, IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has turned out to cause interoperability problems. This note spells out the most important difference; that an IPv6 address isn't automatically associated with an IPv6 on-link subnet prefix. "PPP Over Ethernet (PPPoE) Extensions for Scaled Credits and Link Metrics", Bo Berry, 18-Dec-07, This document specifies a method for optional flow control credit scaling and link quality metric scaling for Point-to-Point over Ethernet (PPPoE). Credit and metric scaling is required when connecting to high performance devices that employ the PPPoE credit flow control and link metric reports as defined in RFC 4938. "Home Agent assisted Route Optimization between Mobile IPv4 Networks", Antti Mäkelä, Jouni Korhonen, 22-Feb-08, This document describes a Home Agent assisted route optimization extension to IPv4 Network Mobility Protocol. "IANA Considerations for the IPv4 and IPv6 Router Alert Option", Andrew McDonald, Jukka Manner, 25-Feb-08, This document provides new instructions to IANA on the allocation of IPv4 and IPv6 Router Alert Option Values. "Simple Protocol for Robust IP/*/IP Tunnel Endpoint MTU Determination (sprite-mtu)", Fred Templin, 16-Nov-07, The nominal Maximum Transmission Unit (MTU) of today's Internet has become 1500 bytes, but IP/*/IP tunneling mechanisms impose an encapsulation overhead that can reduce the effective path MTU to smaller values. Additionally, existing tunneling mechanisms are limited in their ability to support larger MTUs. This document specifies a simple protocol for robust IP/*/IP tunnel endpoint MTU determination (sprite-mtu). "Prefer Header for HTTP", James Snell, 15-Feb-08, This specification defines a new HTTP header that can be used by a client to request that certain behaviors be implemented by a server while processing a request. "Checksum Ciphersuites for the Bundle Protocol", Wesley Eddy, Lloyd Wood, Will Ivancic, 11-Mar-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, Hannes Tschofenig, 19-Nov-07, 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, 7-Feb-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, 13-Mar-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. "Kernel Metadata and Electronic Resource Citations (ERCs)", John Kunze, Andrian Turner, 10-Oct-07, Kernel metadata is a small prescriptive vocabulary designed to support highly uniform but minimal object descriptions for the purpose of orderly collection management. The Kernel vocabulary, based on a subset of the Dublin Core (DC) metadata element set, aims to describe objects of any form or category, but its reach is limited to a small number of fundamental questions such as who, what, when, and where. The Electronic Resource Citation (ERC), also specified in this document, is an object description that addresses those four questions using Kernel and other metadata elements. "Binary Floor Control Protocol over UDP", Geir Arne Sandbakken, Trond Andersen, Alfred Heggestad, 10-Oct-07, This memo extends the Binary Floor Control Protocol enabling it to use UDP as a transport. In order to use an unreliable transport mechanism this draft utilizes the existing transaction model in BFCP to achieve reliability. Each request now has an appropriate response to complete the transaction. It also defines a keep alive behavior needed to keep NAT bindings open. "Specifying Holes in LoST Service Boundaries", James Winterbottom, Martin Thomson, 10-Oct-07, This document describes how holes can be specified in service boundaries. One means of implementing a solution is described. "Diameter Grid Accounting Application", Cristian Morariu, 11-Oct-07, This document specifies a Diameter application in support of accounting in Grid networks. It defines a way to integrate network- related and Grid service-related accounting parameters to ensure the operation of a homogeneous accounting systems based on Diameter. A new set of AVPs is defined and accounting messages are extended in order to support accountable and exchangeable Grid services in a multi provider environment. "Agent-based multicast support for moving networks (NEMO)", Dirk von Hugo, 25-Oct-07, This document describes an approach to support multicast listeners and senders located within a moving IPv6 network (NEMO). A NEMO is built up by at least one Mobile Router (MR) and a set of Mobile Network Nodes (MNNs). The MR handles all routing related tasks to provide connectivity between the MNNs and an access network including mobility management. Correspondingly the MR also subscribes to multicast groups and forwards emerging multicast traffic on behalf of a MNN. For optimised routing of multicast data a hierarchical multicast agent is introduced as a logical entity providing an anchor to the multicast tree. In the MR a corresponding functionality is defined which decides on the location of the specific agent to be used for a distinct multicast traffic. "Principles of Internet Host Configuration", Bernard Aboba, Dave Thaler, Loa Andersson, 20-Mar-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. "DHCPv6 Bulk Leasequery", Mark Stapp, 15-Oct-07, 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 specifies extensions to the Leasequery protocol that add new query types and allow for bulk DHCPv6 binding data transfer. "Simple procedures for Detecting Network Attachment in IPv6", Suresh Krishnan, Greg Daley, 25-Feb-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. "Framework for Performance Metric Development", Alan Clark, 25-Feb-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. "Problems with Flow Collection in Large-Scale Networks", Atsushi Kobayashi, 21-Feb-08, Flow measurement techniques have been developed in order to cope with increasing bandwiths. Flow measurement is currently being used as a popular method for monitoring large networks, e.g. at Internet Service Providers or multinational corporations, for accounting, management, and security purposes. To construct the measurement system for such networks, the biggest challenge is scalability. Whereas packet sampling functions in current flow measurement solutions such as NetFlow/sFlow/IPFIX help to approach this issue, some problems still remain. This document describes such open issues, which a flow-based measurement system might encounter in large-scale networks. The results are intended to be used to define and to develop an IPFIX Mediator device. "MIPv6 Correspondent Node-Targeted Location Privacy and Optimized Routing", Kilian Weniger, 16-Oct-07, Mobile IPv6 does not allow a mobile node to hide its location from a correspondent node without compromising optimized routing. Hence, a mobile node has the choice: it can either get location privacy support or short packet delay, but not both at the same time. This document discusses the problem of achieving both simultaneously and specifies a solution. The solution utilizes the Mobile IPv6 bootstrapping mechanisms and does neither introduce new network entities nor changes to home agent or correspondent node implementations. "IPsec Gateway Failover Protocol", Yaron Sheffer, Hannes Tschofenig, Lakshminath Dondeti, Vidya Narayanan, 19-Mar-08, The Internet Key Exchange version 2 (IKEv2) protocol has computational and communication overhead with respect to the number of round-trips required and 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. "Ethernet preamble variation - Use Ethernet preamble to perform frame's classification and a switching optimization", Daniele Giordano, 3-Nov-07, Ethernet, standardized as IEEE802.3, is a family of frame-based networking technologies for local area networks. It's the most widespread wired LAN technology. This document proposes a variation of the original frame's structure to perform a frame's classification and a switching optimization (fundamental steps for QoS mechanism). "Priority of transport method for fax over IP", Daniele Giordano, 3-Nov-07, In order to fax over IP networks different methods can be used. In many countries fax are legal documents. What is the best way to deliver fax? What is the most reliable method? This document proposes a priority of transport method for fax over IP. "Using Device-provided Location Measurements in HELD", Martin Thomson, James Winterbottom, 10-Dec-07, A method is described by which a Device is able to provide measurement data to a LIS within a HELD request. Measurement information are observations about the position of a Device, which could be data about network attachment or about the physical environment around the LIS. 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 measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters. "Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", Eiji Oki, 23-Oct-07, 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. "BGP/IP VPNs: BGP and CE-Based Virtual Private Networks", Lou Berger, Ronald Bonica, Russ White, 24-Oct-07, This memo describes a routing architecture that is most applicable to Customer Edge (CE)-based Virtual Private Networks (VPNs). In this architecture, customer devices use BGP to exchange VPN routes with one another. The BGP UPDATES include a new attribute that identifies the endpoint of a tunnel that can be used to reach a particular VPN prefix. The encapsulation strategy described in this memo is more flexible than that described in RFC 4364. In this architecture, the edge router can encapsulate the original datagram twice, as in RFC 4364. In this case, the inner header provides VPN context and the outer header identifies the tunnel between edge routers. Alternatively, the edge router can encapsulate the original datagram only once, with the tunnel providing both VPN context and identifying a tunnel to the remote edge router.Contents "Stream Control Transmission Protocol (SCTP) Data Acknowledgement with Non-Renegable Selective Acknowledgements (NR-SACKs).", Preethi Natarajan, Paul Amer, Ertugrul Yilmaz, Randall Stewart, Janardhan Iyengar, 24-Oct-07, 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. "P2PSIP bootstrapping using DNS-SD", Gustavo Garcia, 25-Oct-07, This document describes a DNS-based bootstrap mechanism to discover the initial peer or peers needed to join a P2PSIP Overlay. The document specifies the use of DNS Service Discovery (DNS-SD) and the format of the required resource records to support the discovery of P2PSIP peers. This mechanism can be applied in scenarios with DNS servers or combined with multicast DNS to fulfill different proposed P2PSIP use cases. "A Kademlia-based DHT for Resource Lookup in P2PSIP", Simone Cirani, Luca Veltri, 25-Oct-07, This draft describes a Kademlia-based protocol for Resource Lookup in P2PSIP. The proposed protocol is based on dSIP, a SIP-based protocol proposed by other authors as generic framework for a distributed SIP Location Service. Although the dSIP authors have obsoleted the draft by a newer approach based on a binary protocol named RELOAD, we are still considering this SIP-based approach, due to implementation simplicity, possibility of reuse of already available SIP stack implementations, easy integration into existing UAs, minimization of the number of required protocols for a P2P UA, and widespread support for (and relative maturity of) the SIP standard. "URI Scheme for Java(tm) Message Service 1.0", Debao Xiao, 15-Feb-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. "Location Hiding: Problem Statement and Requirements", Henning Schulzrinne, Laura Liess, Hannes Tschofenig, Barbara Stark, Andres Kuett, 29-Mar-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 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. "Call Completion Implementation Details", Dale Worley, 29-Jan-08, This paper gives a detailed discussion of the implementation of "call completion on busy subscriber" and "call completion on no reply" to flesh out the proposed call completion event package. "Sieve Email Filtering: Sieves and display directives in XML", Ned Freed, Srinivas Vedam, 25-Feb-08, This document describes a way to represent Sieve email filtering language scripts in XML. Representing sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools. The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format.Change History (to be removed prior to publication as an RFC Changed representation of comments in XML to use a comment element. Updatde references. "Shimmed IPv4/IPv6 Address Network Translation Interface (SHANTI)", Brian Carpenter, 7-Nov-07, There is a pragmatic need for a packet-level translation mechanism between IPv4 and IPv6, for scenarios where no other mode of IPv4 to IPv6 interworking is possible. The mechanism defined here uses a shim in both the translator and the IPv6 host to mitigate the problems introduced by stateless translation. "Considering availability of free software when evaluating Draft Standards", Brian Carpenter, 5-Nov-07, This draft responds to a request for input by the IPR WG Chair. It proposes that the IETF's criteria for evaluating Draft Standard specifications should preferably include the availability of free software. "Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP", Preethi Natarajan, Paul Amer, Ertugrul Yilmaz, Randall Stewart, Janardhan Iyengar, 25-Feb-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. "Requirements on Fast Message Authentication Codes", David McGrew, Brian Weis, 22-Feb-08, This memo outlines requirements guiding the development of a fast Message Authentication Code (MAC) algorithm suitable for use with many IETF protocols, but in particular routing protocols that use a MAC for packet authentication. It is widely conjectured that secure MACs that are fast in software are possible, and many interesting MACs have appeared in the literature. Nevertheless, none of these MACs have seen broad adoption, and none are a good match for the routing protocol case. We hope that this memo brings together MAC designers and MAC users for a fruitful discussion. "Saratoga: A Scalable File Transfer Protocol", Lloyd Wood, Jim McKim, Wesley Eddy, Will Ivancic, Chris Jackson, 25-Feb-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 uses UDP or 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, 25-Feb-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 describes how the mechanisms defined in the centralized conferencing framework can be used to support Instant Messaging (IM) chat sessions. "Signaling Extensions for Wavelength Switched Optical Networks", Greg Bernstein, 21-Feb-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, 31-Oct-07, This document describes a new approach to handling user mobility at the network layer in the context of Multiprotocol 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 Multiprotocol 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 for Wavelength Switched Optical Networks", Greg Bernstein, 20-Feb-08, This memo provides and information model and compact encodings for information needed for path computation and wavelength assignment in wavelength switched optical networks. Such encodings can be used in extensions to Generalized Multi-Protocol Label Switching (GMPLS) routing for control of wavelength switched optical networks (WSON) or for other mechanisms, e.g. XML based, for conveying this information to a path computation element. "A Feature Set for the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 31-Oct-07, This document defines a protocol feature set for the Extensible Messaging and Presence Protocol (XMPP), in accordance with the concepts and formats proposed by Larry Masinter within the NEWTRK Working Group. "Distributed Universal Resource Name Resolution based on Distributed DNS", Lican Huang, 13-Feb-08, This file is a proposal for P2P based Universal Resource Name resolution based on Internet draft --Distributed DNS Implementation in IpV6[lican]. "CLI forwarding method during call transfer", Daniele Giordano, 4-Nov-07, Many telephony services are IP based and they can use various signaling protocols like H.323, SIP, MGCP, MEGACO and vendor proprietary protocols. This document describe a method to identify and to change the Calling Line Identification (or CLI) field during call forwarding. This method is voice over ip protocol independent. This method can be apply to all voice over ip protocols. "Evaluation of Possible Interior Gateway Protocol Extensions for Wavelength Switching Optical Networks", Dan Li, 1-Nov-07, 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, 1-Nov-07, The behavior of an OCSP server is specified for cases in which the OCSP server is capable of supporting more than one signature algorithm. "Protocol for Federated Filesystems v1.0", Renu Tewari, Manoj Naik, Daniel Ellard, Craig Everhart, 3-Dec-07, 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. "NEMO for Mobile Ad-hoc Networks", Teco Boot, 2-Nov-07, Mobile Ad-hoc Networks could be attached to a fixed infrastructure network, like the Internet. This document specifies a mechanism for Border Router discovery and utilization. It provides facilities for choosing the best Border Router, configuring IP addresses needed for using the selected Border Router and providing a path to the selected Border Router. Seamless transition to alternate Border Routers is provided. When mobile nodes in the MANET make use of Mobile IP or NEMO (NEtwork MObility), session continuity is provided. NEMO for MANET is based on NEMO, which utilizes IPv6 mobility support. The NEMO basic support protocol can easily be enhanced to support IPv4, which provides IPv4 support by NEMO for MANET. "Path Computation Element Communication Protocol (PCEP) Requirements and Extensions for the Support of Wavelength Switched Optical Networks", Young Lee, Greg Bernstein, 20-Feb-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. "M2UA Implementor's Guide", Barry Nagelberg, 2-Nov-07, This document contains a compilation of all defects found since the publication date for M2UA [RFC3331]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of M2UA to clarify errors in the original M2UA document. This document updates RFC3331 and text within this document supersedes the text found in RFC3331. "Internationalizing Domain Names in Applications (IDNA): Protocol", John Klensin, 7-Feb-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. "IETF Patent Policy: A Quantum Approach", Phillip Hallam-Baker, Daniel Weitzner, 4-Nov-07, Considerations for IETF patent policy are considered and proposals made for reform. The particular objective of these proposals is to reduce the amount of time spent in unproductive discussion of IPR issues and to allow Working Groups to provide Patent Rights Holders with clearly defined criteria that must be met in order for their technology to be accepted. "Cryptographic Algorithm Identifiers", Phillip Hallam-Baker, 4-Nov-07, Preferred identifiers for cryptographic algorithms currently in use in Internet standards. "The Session Description Protocol (SDP) WSDL Attribute", Vicente Olmedo, Victor Villagra, Juan Burgos, Georgina Gallizo, 5-Nov-07, This document defines a new Session Description Protocol (SDP) media- level attribute: 'wsdl'. The 'wsdl' attribute allows for a user running Web Services to let a potential client know the Uniform Resource Identifier (URI) where the Web Service Description Language file (WSDL) describing the service can be obtained. The WSDL file describes the public interface offered by the Web Service and allows the client to consume the service. It also defines the SDP proto value 'TCP/HTTP', needed for this type of communication. "A lightweight security extension for the Unidirectional Lightweight Encapsulation (ULE) protocol", Michael Noisternig, Bernhard Collini-Nocker, 5-Nov-07, 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 revision for SIP protocol", Daniele Giordano, 5-Nov-07, Many RFCs and Internet Drafts describe call on hold methods adopted in SIP signaling protocol. The actual implementation may not always be ideal (reasons are explained below). This draft proposes a revision of call on hold method for SIP protocol. "Authorization Certificates for Routers and Proxies", Suresh Krishnan, 5-Nov-07, Secure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for performing router authorization. The certificates that are currently recommended can be used for any purpose. This document specifies the extended key usage values for such certificates which explicitly states the purpose for which these certificates are used. "The IM-ID Header Field", Peter Saint-Andre, 7-Nov-07, This document defines a header field that enables the author of an email or netnews message to include an Instant Messaging (IM) URI in the message header block for the purpose of associating the author with an instant messaging address. "The Presence-ID Header Field", Peter Saint-Andre, 7-Nov-07, This document defines a header field that enables the author of an email or netnews message to include a Presence URI in the message header block for the purpose of associating the author with an address that provides information about network availability, also known as "presence". "Proxying Secure Neighbor Discovery Messages", Suresh Krishnan, 5-Nov-07, Neighbor discovery(ND) proxies provide a method for bridging multiple links into a single subnet. They do this by modifying the neighbor discovery signaling passing through them. SEND provides a way of securing neighbor discovery signaling so that receiving nodes can detect if the neighbor discovery packets have been tampered with. This leads to SEND and ND proxies being unable to coexist with each other. This document proposes a method for these to co-exist. "IANA Registration for an Enumservice Trunkgroup", Richard Shockey, Tom Creighton, 6-Nov-07, 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. "Problem Statement and Requirements for Diameter Prefix Delegation Application", Behcet Sarikaya, Frank Xia, Jouni Korhonen, 22-Feb-08, This document provides problem statement for Diameter prefix delegation application. The document also identifies application scenarios and requirements on Diameter prefix delegation application. "GMPLS RSVP-TE Extensions to Control Ethernet OAM", Attila Takacs, Balazs Gero, 25-Feb-08, The GMPLS controlled Ethernet Label Switching (GELS) work is extending GMPLS RSVP-TE to support the establishment of Ethernet LSPs. 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. This memo specifies extensions of GMPLS RSVP-TE to support the setup of the associated CFM OAM entities for point-to- point Ethernet LSPs. "Hybrid Subscription for Multicast Reciever Mobility in MIPv6", Frank Xia, Behcet Sarikaya, 6-Nov-07, In MIPv6 specification, there are two basic methods for mobile multicast: 1) via a bi-directional tunnel from MN to its Home Agent;2) via a local multicast router on the foreign link being visited. In this memo, a hybrid method is introduced. MN subscribes multicast service through Home agent at first. Then, MN changes its subscription router to a local multicast router which can provide the same multicast service. "Application Scenarios for Peer-to-Peer Session Initiation Protocol (P2PSIP)", David Bryan, Eunsoo Shim, Bruce Lowekamp, Spencer Dawkins, 6-Nov-07, This document attempts to identify and classify application scenarios of P2P based SIP. It does not attempt to exhaustively enumerate these scenarios, and is focused exclusively on scenarios related to real-time IP communication. "OAM for L2 VPN Networks Using CFM and VCCV", Olen Stokes, 7-Nov-07, The IEEE has defined P802.1ag Connectivity Fault Management (CFM) for managing bridged LAN networks. The IETF has defined L2 Virtual Private Networks (VPNs) that provide an emulated LAN service for such bridged networks. These L2 VPNs are created using a collection of one or more point-to-point pseudo wires (PWs). The IETF has also defined Virtual Circuit Connectivity Verification (VCCV) for managing these PWs. This memo discusses the ability of a combination of CFM and VCCV to meet the OAM requirements of a L2 VPN. "Multiple Interfaced Mobile Nodes in NetLMM", Mohana Jeyatharan, 22-Feb-08, The specific mechanism described in the current PMIPv6 draft to support multihoming is such that a different unique prefix is given to each interface of a Mobile Node that is attached to the PMIPv6 domain. However, multihoming can also be provided using single prefix for all interfaces of MN. This memo explores and highlights some issues associated with multihoming support in PMIPv6: using single prefix per MN method or multiple prefixes per MN method. "Multiprefix IPv6 Routing for Ingress Filters", Fred Baker, 7-Nov-07, This note addresses routing in a network that supports multiple prefixes and has different DMZs, in the context of BCPs 38 and 84 (ingress filtering). It proposes a change to the way IPv6 forwarding occurs, and so should be considered carefully by the Internet community. "Cisco IP Version 4 Source Guard", Fred Baker, 7-Nov-07, As requested in the SAVA discussions, this document describes Cisco's IP Source Guard feature. "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching", Lou Berger, Dimitri Papadimitriou, Don Fedyk, 25-Feb-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 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. 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.Contents "OAM (Operation, Administration and Maintenance) for Virtual Private LAN Service (VPLS)", Olen Stokes, 19-Nov-07, This document describes a methodology and a set of mechanisms for Operation, Administration and Maintenance (OAM) of a general VPN (Virtual Private Network) service, that is applied here to a Virtual Private LAN Service [RFC4761][RFC4762]. [L2VPN-CFM] describes the capabilities of CFM [802.1ag] and VCCV [VCCV] for OAM operations among the bridge module components in the VPLS. The OAM functions described in this document builds the additional capabilities into VPLS OAM to detect, verify and isolate connectivity faults among the VPLS forwarder components. The methodology adopted extends LSP Ping concepts described in [RFC4379] and VCCV capabilities described in [VCCV]. "YANG - A data modeling language for NETCONF", Martin Bjorklund, 5-Feb-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. "Network Time Protocol (NTP) Server Option for DHCPv6", Richard Gayraud, Benoit Lourdelet, 14-Feb-08, The NTP Server Option for DHCPv6 provides NTPv4 (Network Time Protocol version 4) configuration information to DHCPv6 hosts. "OSPF Transport Instance Extensions", Acee Lindem, 7-Nov-07, 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. "LoWPAN Backbone Router", Pascal Thubert, 7-Nov-07, 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. "MIKEY Capability Discovery", Seokung Yoon, Joongman Kim, Yoojae Won, 7-Nov-07, This document describes a negotiation procedure to reduce the number of roundtrip defined in RFC 3830 for seeking a common set of parameters between user agents. "IP Transmission over IEEE 802.16 Networks", Sang-Eon Kim, Joo Yoon, 7-Nov-07, This draft describes IP packet transmission over IEEE 802.16 network to access Internet with PMP mode based IP CS. IP CS is a payload of IPv4 packet and IPv6 packet over IEEE 802.16 frame. This draft introduces host based packet delivery mechanism that can be classified layer 2 forwarding and IP tunnel based on public service and trial on IEEE 802.16 network. It describes HBPD on IEEE 802.16, requirements of the network elements and how to control IP CS on the IEEE 802.16. "Session Initiation Protocol Service Example -- Music on Hold", Dale Worley, 16-Jan-08, The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is when one party to a call has the call "on hold", the other party receives a media stream (often either music or advertising). 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. "Prefix Distribution Framework for Connected MANETs", Kenichi Mase, Kazuki Akima, 8-Nov-07, Table of Contents "Channel Binding Identifiers for Secure Shell Channel", Nicolas Williams, 8-Nov-07, This document defines the channel bindings for SSHv2 connections. "SMTP Service Extension for Indicating Message Authentication Status", Murray Kucherawy, 8-Nov-07, 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. "Proactive Correspondent Registration for Proxy Mobile IPv6 for Route Optimization", Pyung-Soo Kim, Sang-Eon Kim, Jong-Sam Jin, 8-Nov-07, In this document, a proactive correspondent registration mechanism is proposed for the Proxy Mobile IPv6 (PMIPv6) route optimization between the correspondent node (CN) and the mobile access gateway (MAG) on behalf of the mobile node (MN). Two scenarios are considered according to the type of CN. For the proposed mechanism, the proxy home test and the concurrent care-of test are defined newly with parameters specified by information on candidate MAGs. The proposed correspondent registration mechanism is performed before actual handover for candidate MAGs where the MN can attach newly. Therefore, the proposed mechanism can reduce correspondent registration latency, which can reduce handover latency and thus enhance throughput degradation caused by the bidirectional tunneling via the local mobility anchor (LMA). "GMPLS Signaling Extensions for Optical Impairment Aware Lightpath Setup", Giovanni Martinelli, Andrea Zanardi, 22-Feb-08, The problem of provisioning a lightpath in a transparent dense wavelength division multiplexing (DWDM) optical island requires the evaluation of of the optical impairments along the selected route. In this draft we propose a GMPLS signaling protocol (RSVP/RSVP-TE) extension to collect and provide the egress node the optical impairment parameters needed to validate a lightpath setup request feasibility. "Source address validation in the local environment", Fred Baker, 8-Nov-07, This note describes how Source Address Validation might be applied in an IPv6 environment. Local systems should be able to ensure that their peers are using the IPv6 source addresses that the routing system uses to deliver data to them. Remote systems should be able to ensure that traffic they forward has reasonable source addresses. "Format for Domain Reputation Data", Paul Hoffman, John Levine, 19-Feb-08, This document describes two formats for reputation data for domains. The smaller format contains data that is expected to be used in real- time receiver decisions, while the larger format is used for more complete data that is appropriate for off-line decision making. "New ASN.1 Modules for CMS and S/MIME", Paul Hoffman, Jim Schaad, 8-Nov-07, 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. "Problem Statement and Requirement: Mobile Multicast", Hui Deng, Peng Yang, 20-Feb-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. "Solution approaches for address-selection problems", Arifumi Matsumoto, 8-Nov-07, 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. "The SIP INFO Method and Info Package Framework", Hadriel Kaplan, Christer Holmberg, 25-Feb-08, This document defines the INFO method and a mechanism for defining, negotiating and exchanging Info Packages in it. INFO requests are used within SIP INVITE-created dialogs, for applications which need to exchange session-related information inside the INVITE-created dialog. This draft addresses issues and open items from RFC 2976, and replaces it. "Requirement for Multicast MPLS/BGP VPN Partitioning", Maria Napierala, 25-Feb-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. "Using HELD for Inter-LIS Communication", James Winterbottom, Martin Thomson, 9-Nov-07, This document describes how HELD can be used to support LIS to LIS communication. "Load Balancing Fat MPLS Pseudowires", Stewart Bryant, Clarence Filsfils, Ulrich Drafz, 19-Feb-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 two methods of achieving that, the one by including an additional label in the label stack, the other by using a block of alternative pseudowire labels. "Considerations for Civic Addresses in PIDF-LO", Karl Wolf, Alexander Mayrhofer, 19-Feb-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 elements to the PIDF Location Object (PIDF-LO) elements. "Service Extensible P2P Peer Protocol", XingFeng Jiang, Hewen Zhang, 22-Feb-08, This document describes the Service Extensible Protocol (SEP), which is the peer protocol spoken between P2PSIP Overlay peers to share information and organize the P2PSIP Overlay Network. SEP uses a flexible forwarding mechanism to avoid congestion in the Overlay. It also proposes a general service discovery method and a built-in NATtraversal mechanism. By using these methods, SEP tries to improve the success rate and reduce the latency of the transaction. "Flow Distribution Rule Language for Multi-Access Nodes", Conny Larsson, Michael Eriksson, Koshiro Mitsuya, Kazuyuki Tasaka, Romain Kuntz, 9-Nov-07, 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. "On the use of TLS Session resumption and SASL EXTERNAL", Dave Cridland, 9-Nov-07, Some SASL mechanisms provide a fast reauthentication option. TLS also provides this, and this memo outlines a proposal to use the TLS session resumption as a method for mechanism-independent fast reauthentication using SASL EXTERNAL. "EID Mappings Multicast Across Cooperating Systems for LISP", Scott Brim, Dino Farinacci, Dave Meyer, John Curran, 9-Nov-07, One of the potential problems with the "map-and-encapsulate" approaches to routing architecture is that there is a significant chance of packets being dropped while a mapping is being retrieved. Some approaches pre-load ingress tunnel routers with at least part of the mapping database. Some approaches try to solve this by providing intermediate "default" routers which have a great deal more knowledge than a typical ingress tunnel router. This document proposes a scheme which does not drop packets yet does not require a great deal of knowledge in any router. However, there are still some issues that need to be worked out. "Comparison of Proposed PCN Approaches", Anna Charny, 9-Nov-07, Several, sometimes conflicting proposals have been offered for the consideration of the PCN WG regarding PCN internal node and PCN edge node behaviors. Based on the WG charter, the WG needs to make a decision on which of the proposed PCN-interior-node and PCN-boundary- nodes behaviors to endorse. The primary goal of this draft is twofold. First, we attempt to summarize the functional differences between the proposed alternatives. Second, we provide a brief summary of performance evaluation results. Finally we propose a view on how a (parameterized) specification of the PCN-interior-node metering and marking function can be described to enable several of the proposed behaviors. We argue that if this parameterized specification is used for specifying the PCN-interior-node behavior, then it can support a range of behaviors at the PCN-boundary-node. The decision on which of the PCN-boundary-node behaviors to choose can then be considered separately. We also discuss complexities associated with choosing such uniform approach. "Inter-Technology Handover for Proxy MIPv6", Marco Liebsch, Long Le, 25-Feb-08, The IETF is specifying Proxy Mobile IPv6 for network-based localized mobility management, which takes basic operation for registration, tunnel management and de-registration into account in a first protocol release. This document proposes an extension to Proxy Mobile IPv6 to suit MNs, which have multiple network interfaces implemented and hand over from one network interface to another network interface while remaining anchored at the same Local Mobility Anchor. This extension avoids that the LMA will prematurely forward data packets for the mobile node to the mobile node's new interface before the address configuration of this interface has completed. With the proposed extension, packet buffering at the new MAG is not necessary and packet losses during an inter-technology handover can be avoided. "Media Control Channel Framework (SCFW) Call Flow Examples", Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Simon Romano, 11-Mar-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. "Peer-to-Peer Name Service (P2PNS)", Ingmar Baumgart, 9-Nov-07, This document describes P2PNS, a secure distributed name service for P2PSIP. P2PNS can be used to resolve SIP AoRs to Contact URIs without using DNS or central SIP servers. P2PNS provides several security mechanisms to efficiently prevent identity theft and to ensure the uniqueness of SIP AoRs in a completely decentralized and untrusted network without login servers. The proposed proxy architecture allows a seamless integration of legacy SIP UAs, avoids modifications to the complex SIP protocol stack and facilitates the deployment of P2PSIP networks. Because P2PNS provides a generic name service it is not limited to P2PSIP but can also be used e.g. to build a distributed DNS system. "SMTP Transferred-By-Reference (TBR) Extension", Douglas Otis, John Leslie, 9-Nov-07, This document describes an extension to SMTP that allows email to be exchanged as a storage system immutable XAM (eXtensible Access Method) reference. When MTAs employ the TBR mode, message origination can not be spoofed, and message acceptance is not asserted until retrieval of the referenced message. This strategy ensures a minimal SMTP overhead, increasing the responsibility of senders in order to limit the load of unwanted messages upon receivers. In addition, the TBR extension requires an [RFC2821] MAIL FROM address in the same domain as the server from which the XAM will be fetched, so that a dependable status-reporting path is assured. "SIP-based Bicasting for Seamless Handover between Heterogeneous Networks", Haruki Izumikawa, Ross Lillie, 25-Feb-08, A vertical session handoff occurs in heterogeneous networks when a session media is moved between access networks within the same device. During session handoff, bi-casting media streams to both access networks of the session's device may be desirable to insure a seamless session handoff. This document describes the general methods and specifies the signaling and media flows for providing this service using the Session Initiation Protocol (SIP) [1]. "BGP IPSec Tunnel Encapsulation Attribute", Lou Berger, Russ White, Eric Rosen, 24-Feb-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.Contents "MVPN Profiles Using PIM Control Plane", A Boers, Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 9-Nov-07, The MVPN (Multicast Virtual Private Network) architecture, as specified in [MVPN], 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 three profiles that use a PIM control plane. "GMPLS Ethernet Label Switching Architecture and Framework", Don Fedyk, Lou Berger, Loa Andersson, 10-Nov-07, There has been significant recent work in increasing the capabilities of Ethernet switches. 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 "Proposed Host Identity Protocol (HIP) Checksum Coverage", XingFeng Jiang, Philip Matthews, Spencer Dawkins, 10-Nov-07, This specification suggests two changes to the Host Identity Protocol (HIP) checksum calculation. Specifically, only the HIP header and payload fields would be included in the checksum calculation, and the CRC32c algorithm would be used to compute the checksum. The HIP version number would be incremented if these suggestions are accepted, to reflect a different checksum algorithm. "Loop Detection for MANET", Kenichi Mase, Lee Speakman, Kazuki Akima, Yasunori Owada, 10-Nov-07, We consider looping issue of a mobile ad hoc network (MANET). Transient routing loops have been observed to form in Ad-hoc Networks running the MANET routing protocol with Link Layer Notification (LLN). Even when only a small quantity of the traffic may enter these loops and only for brief time, the effect is to significantly increase the impact on the surrounding network and its traffic thus degrading end-to-end transmission. The use of MANET routing protocols with LLN, together with loop detection and discarding of looping packet to negate the detrimental effects on surrounding traffic is found to improve performance significantly. "Industrial Routing Requirements in Low Power and Lossy Networks", Dust Networks, Rick Enns, JP Vasseur, Pascal Thubert, 10-Nov-07, 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. For wireless devices to have a significant advantage over wired devices in an industrial environment the wireless network needs to have three qualities: low power, high reliability, and easy installation and maintenance. The aim of this document is to analyze the requirements for the routing protocol used for low power and lossy networks (L2N) in industrial environments. "A Session Initiation Protocol (SIP) Response Code for Interactive Connectivity Establishment (ICE) Failures", Jonathan Rosenberg, 23-Feb-08, Interactive Connectivity Establishment (ICE) defines an extension to the offer/answer model used by the Session Initiation Protocol (SIP). This extension allows endpoints to traverse firewalls and NATs. However, in cases where highly restrictive firewalls exist, or where network failures have occurred, ICE may not be able to successfully find a media path. This document provides an error response code that can be used with SIP in these cases. "Requirements for SIP Resource Priority Header in SIP Responses", Janet Gunn, Tim Dwight, Martin Dolly, 10-Nov-07, The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. The Internet Draft "Allowing SIP Resource Priority Header in SIP Responses" (draft-polk-sip-rph-in-responses-00) describes a modification to RFC4412 to permit RPH in responses. This document describes one of the requirements associated with systems using RPH, that could be satisfied by the modification of RFC 4412 to permit RPH on responses, and is not easily met by other methods. This ID provides additional motivation for SIP RPH in Responses. "Guidelines for firewall administrators regarding MIPv6 traffic", Suresh Krishnan, Niklas Steinleitner, QIU Ying, Gabor Bajko, 25-Feb-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, 25-Feb-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. "Teredo Security Updates", Suresh Krishnan, James Hoagland, 25-Feb-08, Additional security concerns with Teredo are documented, beyond what is in RFC 4380. This is based on an independent analysis of Teredo's security implications. The primary intent of this document is to describe the updates required to update the Teredo specification. "Fast Handovers for Proxy Mobile IPv6 without Inter-MAG Signaling", Pyung-Soo Kim, Sang-Eon Kim, Jong-Sam Jin, 10-Nov-07, To reduce handover latency for Proxy Mobile IPv6 (PMIPv6), this document proposes an alternative fast handover mechanism where only LMA exchange signaling with MAGs to set up the fast handover. That is, unlike existing mechanisms, inter-MAG signaling is not required in a system which operates the proposed mechanism for the fast handover. "DHCPv6 Delegation of Certificates Option", Chip Popoviciu, Ralph Droms, Eric Levy-Abegnoli, 25-Feb-08, The Certificate options for DHCP-PD RFC3633 [4] provide a mechanism to deliver, along with the IPv6 prefix, the certificate or the information needed to obtain a certificate entitling the client router to advertise the prefix delegated to it. This information is neccesary if Secure Neighbor Discovery RFC3971 [6] is used by the devices connected to the DHCP-PD client router. "Real-time text interworking between PSTN and IP networks", Gunnar Hellstrom, Barry Dingle, Arnoud Wijk, Guido Gybels, 10-Nov-07, IP networks can support real-time text communication. SIP-based real- time text is called Text-over-IP or ToIP. PSTN networks support real-time text using textphones (or TTYs). When real-time text is supported by different networks, gateways are needed to provide interoperability. Real-time text capable gateways may also support real-time voice. This specification describes procedures for interworking between ToIP and PSTN textphones using a real-time text capable gateway (RTT gateway). It also describes ways to route calls to RTT gateways for several call scenarios. Procedures that support the phased introduction of RTT gateways and procedures that support the invocation of text channels at any time during the call are included. Interworking of PSTN textphones that do not support simultaneity of voice and text with IP User Agents that support simultaneous voice and text is also described. "Registration of the Real-time-text Media Feature Tag", Gunnar Hellstrom, 10-Jan-08, This memo defines a new Media Feature Tag "real-time-text" for use in SIP registration and session establishment. This is used to indicate if a device capable of text communication has full real-time text capabilities or limitations in its capabilities requiring the users to apply some turn-taking habits.To the RFC editor Please replace y.y with the assigned ASN.1 identifier and XXXX with the RFC number of this specification. "End-Host Authentication for HIP Middleboxes", Tobias Heer, 11-Nov-07, The Host Identity Protocol 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 Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP)", John Elwell, 11-Nov-07, 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. "Mutual Network Endpoint Assessment", Wei Jiwei, Jia Ke, Yin Han, 10-Nov-07, A method for mutual network endpoint assessment is introduced in this document. In current NEA requirements, only the assessment performed by network owner is described. However, for some applications like online business and file sharing, the unilateral assessment is not enough to ensure the two communication parties are both secure Especially in P2P application, the endpoints perform equal responsibility and hence the mutual network endpoint assessment seems more necessary. each endpoint may configure its security assessment policy based on its own security concerns. . "An HTTPS Location Dereferencing Protocol Using HELD", James Winterbottom, Hannes Tschofenig, Henning Schulzrinne, Martin Thomson, Martin Dawson, 11-Nov-07, 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, 11-Nov-07, 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, 11-Nov-07, 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, 11-Nov-07, 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. "A Baisc Profile of the Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", Eric Burger, 11-Nov-07, This document describes a profile of the SIP Event Package "kpml" that enables simple monitoring of DTMF signals and uses XML documents referred to as Key Press Markup Language (KPML). This profile assumes devices of lesser capability that may have trouble parsing subscription requests or producing generic XML documents. This is a profile of RFC 4730, KPML.Conventions used in this document RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. The Application Interaction Framework document [9] provides the interpretations for the terms "User Device", "SIP Application", and "User Input". This document uses the term "Application" and "Requesting Application" interchangeably with "SIP Application". Additionally, the Application Interaction Framework document discusses User Device Proxies. A common instantiation of a User Device Proxy is a Public Switched Telephone Network (PSTN) gateway. Because the normative behavior of a presentation free User Interface is identical for a presentation free SIP User Agent and a presentation free User Device Proxy, this document uses "User Device" for both cases. "Interworking between the Extensible Messaging and Presence Protocol (XMPP) and the Message Session Relay Protocol (MSRP)", Peter Saint-Andre, Eddy Gavita, Nazin Hossain, Salvatore Loreto, 11-Nov-07, This document defines a bidirectional protocol mapping for use by gateways that enable the exchange of messages in the context of a chat session between a system that implements the Extensible Messaging and Presence Protocol (XMPP) and a system that implements the Session Initiation Protocol (SIP), specifically for the latter session-mode messages that use the Message Session Relay Protocol (MSRP). "Proxy Mutual Authentication in SIP", Steve Dotson, Stuart Hoggan, Sumanth Channabasappa, 22-Feb-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. "An Analysis of Centrally Assigned Unique Local Addresses", Margaret Wasserman, 19-Nov-07, There has been discussion within the IETF IPv6 community for some time regarding whether or not to define Centrally Assigned Unique Local Addresses (ULA-Cs). Although many arguments both for and against the definition of ULA-Cs have been raised and repeated, our discussions have not resulted in consensus about whether or not to define this new address type. This document will summarize the arguments for and against the allocation of ULA-Cs, in an attempt to help the IETF IPv6 community reach a decision on this issue. "Source-Specific Media Format Parameters for H.264 and H.264 SVC", Jonathan Lennox, 11-Nov-07, When used in the Session Description Protocol Offer/Answer model, several of the media format parameters for the H.264 video format, and for its Scalabile Video Codec (SVC) extension, describe characterics of the stream an endpoint is prepared to send, not of streams it is prepared to receive. If an endpoint wishes to send multiple streams, these parameters may be incompatible. This document defines how such media format parameters may be given on a per-source basis, using SDP source-specific fmtp attributes. "What Makes For a Successful Protocol?", Dave Thaler, Bernard Aboba, 22-Mar-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. "A method of using IPsec to setup GRE tunnel", Yingzhe Wu, Hui Deng, 11-Nov-07, Provider-Provisioned Virtual Private Network (PPVPN)[RFC4110] uses some forms of IP tunneling schemes to tunnel VPN traffic. Possible candidates are GRE, IP-in-IP, IPsec and MPLS. The candidate tunneling scheme should provide multiplexing capability, as well as dynamic tunnel setup and maintenance capability. Additionally, security is required if the VPN traffic is traversing public Internet or across Service Provider domains. Each above candidate by itself is not sufficient to meet all these requirements. This document describes a method of using IPsec signaling (i.e, IKE) to setup a GRE tunnel. This IPsec GRE tunnel may be used as the candidate tunneling scheme in PPVPN network or remote access compulsory VPN. This document also defines a way how the Key field in GRE header is used in IPsec GRE tunnel setup. "An ID/Locator Architecture for P2PSIP", Eric Cooper, Alan Johnston, Philip Matthews, 25-Feb-08, This document describes an architecture where peers in an peer-to- peer overlay use special IP addresses to identify other peers. Two of the advantages of this approach are that (a) most existing applications can run in an overlay without needing any changes and (b) peer mobility and NAT traversal are handled in a way that is transparent to most applications. "Extension to the ua-profile Event Package to Support the Application Profile Type", Sumanth Channabasappa, Joshua Littlefield, Salvatore Loreto, 21-Feb-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. "Issues and Approaches to Scaling RBridge Deployments", Eric Gray, 19-Nov-07, RBridges are link layer (L2) devices that use routing protocols as a control plane. They combine several of the benefits of the link layer with network layer routing benefits. RBridges may use existing link state routing (without requiring configuration) to improve RBridge to RBridge aggregate throughput. RBridges also Gray Expires May, 2008 [page 1] Internet-Draft Scaling RBridge Deployments November 2007 provide support for IP multicast and IP address resolution optimizations. They are intended to be applicable to similar L2 network sizes as conventional bridges and are intended to be backward compatible with those bridges as both ingress/egress and transit. They also support VLANs (although this generally requires configuration) and otherwise attempt to retain as much 'plug and play' as is already available in existing bridges. There has been a lot of discussion within the TRILL working group about the potential for scaling issues when using IS-IS in combination with (possibly as many as 4K) VLANs. This document is intended to provide information on potential scaling issues and the possible solutions that may be applied in deploying RBridges. Gray Expires May, 2008 [page 2] Internet-Draft Scaling RBridge Deployments November 2007 "Datagram TLS Secure RTP (DTLS-SRTP) Key Transport", Dan Wing, 15-Feb-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 which 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 reduces (and often eliminates) the need to key each SRTP session individually, allowing deployment of several DTLS-SRTP scenarios. "Multicast tunneling optimization for Mobile IPv6", Peng Yang, Hui Deng, 26-Feb-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. "RTCP Reporting by Translators", Geoff Hunt, 12-Nov-07, This memo addresses RTCP reporting by and through RTP translators. It collects existing guidance from RFC 3550, systematises translators' reporting behaviour by considering potential sources of information and the policy-controlled forwarding of such information, considers naming issues in labelling reports, considers methods of control of reporting behaviour, and presents some examples of architectures for reporting. "Extended MKCOL for WebDAV", Cyrus Daboo, 12-Nov-07, This specification extends the WebDAV MKCOL method to allow collections and resources of arbitrary resourcetype to be created and to allow properties to be set at the same time. "On Mobile IPv6 Optimization and Multihoming", Chan-Wah Ng, Keigo Aso, 16-Feb-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, 25-Feb-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. "RTSP 2.0 Asynchronous Notification", Tetsuya Ura, Kenshin Oku, Hiromi Harada, Akira Kobayashi, Martin Stiemerling, 25-Feb-08, Some IPTV deployments that are using the Real Time Streaming Protocol (RTSP) require the ability of the server to notify clients about asynchronous events occurring during an RTSP session. Current deployments typically use the ANNOUNCE method of RTSP 1.0 for sending such asynchronous events from a server to clients by using some proprietary extensions. However, the ANNOUNCE method has been removed from the current RTSP 2.0 draft, leaving the new specification without a mechanism for sending asynchronous messages from the server. This memo describes a use case for such an asynchronous message and proposes a new RTSP 2.0 method. "Diameter Mobile IPv4 Application, Revised", Pat Calhoun, Tony Johansson, Nokia Networks, Tom Hiller, Peter McCann, 12-Nov-07, This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers. "NSIS Extensibility Model", John Loughney, 12-Nov-07, This document discusses the Next Steps in Signaling extensibility model. This model is based upon a two-layer model, where there is a transport layer and a signaling application model. This two-layer provides the ability to develop new signaling applications, while retaining the use of a common transport layer. This document will serve as guidance on how the NSIS architecture can be extended. "Multi-homing in BGP-based Virtual Private LAN Service", Kireeti Kompella, Bhupesh Kothari, Thomas Spencer IV, 12-Nov-07, 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. "Network Selection Support for Protocol for Carrying Authentication for Network Access (PANA)", Yoshihiro Ohba, 12-Nov-07, This document defines an extension to PANA for network selection function. The network selection function allows a PaC to select an ISP (Internet Service Provider) among multiple choices. It also allows NAP (Network Access Provider) authentication and ISP authentication to be performed in separate PANA sessions. "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Roy Fielding, James Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, 12-Nov-07, 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 eight-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. 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. "Definition of Master Key between PANA Client and Enforcement Point", Yoshihiro Ohba, Alper Yegin, 17-Nov-07, This document defines PaC-EP Master Key (PEMK), a master key used between a PANA client and an enforcement point, for bootstrapping lower-layer ciphering. A PEMK is derived from EAP Master Session Key as a result of successful PANA authentication. The PEMK is defined to guarantee cryptographic independence among enforcement points across different types of lower-layers. "HTTP/1.1, part 2: Message Semantics", Roy Fielding, James Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, 12-Nov-07, 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 eight-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. 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, James Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, 12-Nov-07, 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 eight-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. Part 3 defines HTTP message content, metadata, and content negotiation. "HTTP/1.1, part 4: Conditional Requests", Roy Fielding, James Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, 12-Nov-07, 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 eight-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. 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, James Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, 12-Nov-07, 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 eight-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. 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, James Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, 12-Nov-07, 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 eight-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. 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, James Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, 12-Nov-07, 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 eight-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. Part 7 defines HTTP Authentication. "IPv6 RA-Guard", Gunter Van de Velde, Eric Levy-Abegnoli, Chip Popoviciu, Janos Mohacsi, 28-Jan-08, When using IPv6 within a single L2 network segment it is neccesary to ensure that all routers advertising their services within it are valid. In cases where it is not convinient or possible to use SeND [1] a rogue Router Advertisement (RA) [2] could be sent by accident due to misconfiguraton or ill intended. Simple solutions for protecting against rogue RAs are beneficial in complementing SeND in securing the L2 domain for ceratin types of devices or in certain transitional situations. This document proposes a solution to reduce the threat of rogue RAs by enabling layer 2 devices to forward only RAs received over designated ports. "Requirements for a Location Quality of Service (QoS) Information Object", Aeke Busin, Yufeng Jin, Miran Mosmondor, Salvatore Loreto, 19-Nov-07, This document describes requirements for Location Quality of Service (QoS) Information that may be carried both in the Geopriv Layer 7 Location Configuration Protocol (L7 LPC) and in the Location Dereference Protocol (LDP) requests. The Location QoS Information is used for expressing the required or desired level of quality, accuracy, response time, and age of requested Location Information. The resulting Location Information is conveyed in existing location formats wrapped in GEOPRIV privacy extensions to the Presence Information Document Format (PIDF-LO) [RFC4119]. "Limitations exist in IP mobility support applications", Yuankui Zhao, 12-Nov-07, There already exist several mobility support solutions and each solution uses its own method to achieve specific goals.But different solutions may not work properly when they are combined in an integrated application environment because network entities have little information about each other.Specially when PMIP meet with the Nemo network environment something need to be considered more. This document describes several limitations on NEMO application and provides a possible solution. "Performance Evaluation of PCN-Based Algorithms", Michael Menth, Frank Lehrieder, 25-Feb-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. "A SIP-based P2PSIP Client Protocol", LiChun Li, Chunhong Zhang, Yao Wang, Yang Ji, 12-Nov-07, This document presents the motivation, design guidelines and high level descriptions of peer-to-peer session initiation protocol (P2PSIP) client protocol, which is spoken between P2PSIP peers and P2PSIP clients. In this document, the necessity of P2PSIP Client is identified firstly. Then, two fundamental guidelines for our design are explained in details. Following these guidelines, the design of proposed protocol and new extensions to existing SIP (session initiation protocol) are described. Such a SIP-based protocol not only makes itself backward-compatible with the vast existing SIP devices, but also provides extra functions to satisfy some particular requirements raised by P2PSIP. "PIM GR Enhancement for BSR, BIDIR and SM", Archana Patel, Janardhan Kulkarni, 12-Nov-07, This document suggests the GR enhancement for BSR, BIDIR and PIM-SM. -This draft suggests a mechanism to refresh E-BSR state and to learn RP-Set on Rebooted E-BSR Router quickly. -This draft suggests a mechanism for PIM-BIDIR Downstream Routers to refresh the (*, G) state only after 'Rebooted Upstream Router has learnt the RP Information and DF election is complete'. -This draft suggests a mechanism for PIM-SM Downstream Router to delay the (*, G) joins to allow RP Information to be learnt on Rebooted Upstream Router. It also suggests the mechanism to refresh the Assert-Winner or Assert-Loser state on Rebooting Router. "An Extensible Data Format (XML) for Describing Files", Miguel Garcia-Martin, Marcin Matuszewski, 12-Nov-07, This document defines an Extensible Data Format (XML) for describing files. "Mapping STUN and TURN messages on HIP", Pekka Nikander, Jan Melen, Miika Komu, Marcelo Bagnulo, 19-Nov-07, This memo defines how one can map the STUN and TURN functionality, as used by ICE, to HIP. "Interactions between CGA and DHCPv6", Iljitsch van Beijnum, 12-Nov-07, Cryptographically Generated Addresses as defined for IPv6 Secure Neighbor Discovery are generated locally on the host using the CGA. However, it can be desireable for other systems to be involved in the generation and use of CGAs in a number of ways: offloading the heavy cryptography for generating or validating CGAs, proxy-generation of CGAs for hosts that don't support the CGA-related protocols themselves or registration of CGA addresses for the purposes of central address administration. When additional hosts are involved in aspects of CGA, it's necessary to discover these other hosts and/or additional configuration items such as the Sec value. The DHCPv6 is a natural choice for doing this. This document provides an overview of the opportunities and issues in this area. "Pseudowire Emulation MPLS PSN Congestion Status Bit", Matthew Bocci, Mustapha Aissaoui, Luca Martini, 12-Nov-07, Draft-ietf-pwe3-congestion-frmwk-00.txt [2] describes requirements for a PE providing a PWE3 service to take action if congestion is detected in the underlying PSN. This draft provides a control plane mechanism to enable a downstream PE detecting congestion to signal that congestion state to an upstream PE so that it may take appropriate action on its PWs. "Problem Statement and Requirements for Route Optimization in PMIPv6", Sangjin Jeong, Christian Vogt, Ryuji Wakikawa, Marco Liebsch, Shinta Sugimoto, Behcet Sarikaya, 19-Nov-07, This document provides the problem statement for route optimization in Proxy Mobile IPv6 (PMIPv6). It also investigates design goals and requirements for route optimization considering the characteristics of Proxy Mobile IPv6. "Ad-Hoc IP Autoconfiguration Solution Space Analysis", Carlos Bernardos, Maria Calderon, Hassnaa Moustafa, 8-Apr-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, Patrick Stupar, 12-Nov-07, 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. "Interactions between PMIPv6 and MIPv6: Route Optimization Issues", Genadi Velev, Kilian Weniger, 25-Feb-08, The interactions scenarios between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) protocols are described in [ID-MIP-PMIP]. This document analyzes these scenarios when route optimization is used. The analysis results in the identification of possible issues that should be considered in the design of extensions for Route Optimization in PMIPv6. "IANA Registration for Encrypted ENUM", Ben Timms, Jim Reid, Jakob Schlyter, 12-Nov-07, 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, 7-Feb-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. "The NKEY DNS Resource Record", Jim Reid, Jakob Schlyter, Ben Timms, 12-Nov-07, A DNS Resource record which can be used to encrypt NAPTR records is described in this document. "The Zone Status (ZS) DNS Resource Record", Jim Reid, 12-Nov-07, A Domain Name System (DNS) resource record which provides status information about a zone is described in this document. "Requirements for domain marking for the purpose of Upstream Traffic Characterization", David Schwartz, Diego Besprosvan, 12-Nov-07, SIP as defined in RFC 3261 [1] defines a Via header as a construct to be used for upstream response routing and for downstream assistance in loop detection. There is an increasing need on downstream administrative domains (ADs) to gain visibility into all the ADs in its upstream path. The information needed is not IP based as internal architectures at upstream ADs is of no consequence to downstream ADs. Logical domain marking, however, is desperately needed for any traffic analysis to occur at the receiving side. Gathering AD information from Via headers is non obvious and in many instances nearly impossible. This documents identifies the requirements for addressing this issue. "IGMP/MLD Error Feedback", Thomas Morin, 12-Nov-07, This document describes messages and procedures that can optionnaly be implemented in IGMP/MLD Queriers and Hosts, to provide information to terminals on the reason why the IGMP/MLD Querier didn't take into account a Membership Report message. "On Providing Light SeND and Privacy Extensions for Proxy MIPv6 (PMIPv6)", Wassim Haddad, Suresh Krishnan, 12-Nov-07, This document describes a light and CGA free version of the secure neighbor discovery protocol combined with a privacy extension for the Proxy Mobile IPv6 protocol. "Multicast blackhole mitigation with PIM adjacency conditions on routing announcements", Thomas Morin, Gregory Cauchie, 25-Feb-08, In a network running PIM-SM, multicast traffic can fail to be properly routed and forwarded during some period of time after a topology change, when unicast routing converges to a new path using a new next-hop before multicast routing adjacencies are fully setup with this new next-hop. At this point, a blackhole appears in the multicast topology and persists until the PIM adjacency become fully setup. This document describes different procedures aiming at avoiding such blackholes, focusing on the use of non-congruent unicast routing that takes into account the status of PIM adjacencies. "The Zone Status (ZS) DNS Resource Record", Jim Reid, 12-Nov-07, A Domain Name System (DNS) resource record which provides status information about a zone is described in this document. "Proxy MIPv6 support for Mobile Nodes with Multihoming", Ahmad Muhanna, Mohamed Khalil, 12-Nov-07, Proxy Mobile IPv6 is a network-based mobility protocol which provides IP mobility for a regular IPv6 mobile node without the involvement of the IPv6 host. Whenever a mobile node is attached to a PMIPv6 domain via a mobility access gateway, MAG, it appears to the mobile node as if it is attached to the same home link and thus the mobile node may think that it is not roaming away from home. An issue has been raised with respect to the base PMIPv6 protocol support of a mobile node with multiple physical interfaces. This issue has been referenced as PMIPv6 support for multihoming mobile node. This document describes the multihoming issue as it relates to PMIPv6 and provides an analysis to all scenarios that have been identified thus far. "Modified Network Address Translation - Protocol Translation", Iljitsch van Beijnum, 19-Nov-07, A smooth transition from IPv4 to IPv6 requires that either all hosts are upgraded to dual stack before the first hosts can become IPv6- only, or that there be some mechanism for IPv6-only hosts to talk to IPv4-only hosts. Expecting the former within a reasonable timeframe isn't realistic, based on current adoption of dual stack combined with the latest projections for the IPv4 depletion that point to a date early in the next decade. And the IETF has recently deprecated the main mechanism that allows the latter: NAT-PT. This document proposes modifications to NAT-PT that address the reasons why the mechanism was deprecated. This should allow future deployment of the modified NAT-PT as an IPv4-to-IPv6 transition mechanism, giving operators the option of running their networks largely IPv6-only. "Network Address Translation (NAT) Behavioral Requirements for DCCP", Remi Denis-Courmont, 20-Feb-08, This document defines a set of requirements for NATs that handle DCCP. "Applications and Media Information (AMI) Extension to the Presence Information Data Format", Henning Schulzrinne, Yang Zhao, 12-Nov-07, The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. The Application and Media Information (AMI) format described here is an extension that adds optional elements to the Presence Information Data Format (PIDF), describing what music a presentity is listening to, what video it is watching, or what game it is playing. "IETF Statement on IPv4 Exhaustion and IPv6 Deployment", Thomas Narten, 12-Nov-07, Over the last year, the Internet community has slowly come to realize that the IANA and RIR IPv4 free address pool will be exhausted within no more than 3-4 years, and possibly sooner. At that point, it will become increasingly difficult for ISPs and end sites to obtain the public IPv4 address space they need to expand operations. IPv6 was developed to address the IPv4 address exhaustion problem, but widespread deployment has barely begun. This document reiterates the IETF's support and continued commitment to IPv6. IPv6 deployment is still necessary to ensure the continued growth and expansion of the Internet. Deployment of IPv6 is needed to preserve important Internet properties that have made it a success and enable new generations of applications and services. "Carrying DHCP options over Neighbor Discovery Messages", Suresh Krishnan, 12-Nov-07, DHCP options are used to convey network and host configuration information to the hosts attached to a network. Some networks may wish to configure their routers to advertise these same pieces of information, and might use IPv6 Router Advertisements do distribute these parameters. This document defines a generic neighbor discovery option for carrying DHCP options. This option is carried over IPv6 Router Advertisements. "Extended URLFETCH for binary and converted parts", Dave Cridland, 7-Feb-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. "Rogue IPv6 Router Advertisement Problem Statement", Tim Chown, Stig Venaas, 12-Nov-07, When deploying IPv6 networks, whether IPv6-only or dual-stack, routers are configured to use IPv6 Router Advertisements to convey information to on link 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, in some networks 'bogus' RAs are observed, which may be present due to misconfigurations or possibly malicious attacks on the network. In this draft we summarise the scenarios in which rogue RAs may be observed, and we present a list of possible solutions to the problem. The goal of this draft is 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, 12-Nov-07, IPFIX supports the concept of an 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 discarding and aggregating received information. This document introduces a number of extensions to the IPFIX Protocol and IPFIX Information Model that support the export of aggregated IPFIX data. In particular, techniques are introduced that optimize the transport of descriptive information. Thus, more information can be preserved in the transmission while further reducing both the number and the size of IPFIX messages. All the proposed extensions are directly applicable to the IPFIX Mediator but can be used in many different applications as well. "DTMF Info-Event Package", Hadriel Kaplan, Christer Holmberg, 12-Nov-07, This document defines a specific SIP Info-event package, based on the generic framework of draft-kaplan-sip-info-events-00.txt, for the purpose of exchanging DTMF events. Kaplan Expires May 12, 2008 [page 1] DTMF Info-Event Package November 2007 "A Secure and Efficient Handover Authentication in FMIP6", Souhwan Jung, Jaeduck Choi, 25-Feb-08, This document describes a secure and efficient handover authentication (SEHA) protocol in FMIP6. The main idea is using the Diffie-Hellman (DH) algorithm to enhance security aspects, and is modifying the DH key exchange to reduce computational cost at the Mobile Node (MN) by delegating exponential operation to the Access Router (AR). The MN and NAR establish the handover key HK_NAR through the PAR instead of the AAA server at any convenient time while the MN belongs to the NAR domain. The HK_NAR is used for handover authentication when the MN moves from the NAR to the next NAR. The main advantage of this document is more secure and suitable to a light-weight mobile terminal than the existing handover authentication scheme using SEND. "MPLS and Ethernet OAM Interworking", Dinesh Mohan, 13-Nov-07, 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 both completed, and this document specifies the mapping of defect states between Ethernet ACs and corresponding Ethernet PWs. "Problem Statement: We Don't Have To Do Fairness Ourselves", Bob Briscoe, T Moncaster, Anne-Louise Burness, 12-Nov-07, Nowadays resource sharing on the Internet is largely a result of what applications, users and operators do at run-time, rather than what the IETF designs into transport protocols at design-time. The IETF now needs to recognise this trend and consider how to allow resource sharing to be properly controlled at run-time. "Network Scaling with Aggregate LSPs", George Swallow, Jim Guichard, 13-Nov-07, 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. "Layer 2 Relay Agent Information", Bharat Joshi, Pavan Kurapati, 13-Nov-07, 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 closest Layer 2 device 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. "Additional XML Security Uniform Resource Identifiers (URIs)", Donald Eastlake 3rd, 13-Nov-07, This document expands and updates the list of URIs intended for use with XML Digital Signatures, Encryption, Canonnicalization, and Key Management specified in RFC 4051. These URIs identify algorithms and types of information. "Ping and Traceroute with Evidence Collection in Photonic Networks", Zafar Ali, University Milan, University Milan, Cisco Systems, University Milan, University Milan, University Milan, 25-Feb-08, Z. Ali, et Al. Expires August 2008 [page 1] Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 [RFC4379] describes procedures for ping and tracerouting for LSPs with PSC (packet switch capable) transit switching capability. An important implication of using transparent (non-PSC) nodes in GMPLS network is that LSP Ping solution described in [RFC4379] are not applicable to LSP with non-PSC switching capability. Another important difference between PSC and non-PSC switching technologies is the data and control plan separation in the latter case. An implication of the separation of data and control planes in GMPLS networks is that LSP traceroute procedures described in [RFC4379] are not directly applicable to GMPLS networks with separation of data and control planes. The scope of this draft is cases where data plane does not provide the OAM functions addressed by this draft. This document is assumed that OAM mechanisms provided by the underlying data plan technology MUST be used, whenever possible. E.g., G.709 addresses the problem of trace routing in DWDM network. However, G.709 OAM mechanisms are only applicable to OEO (Optical-Electrical-Optical) capable node. This document fills in such gaps; in particular it addresses GMPLS OAM functionality in optical networks with wavelength routers, ROADMs nodes, etc. with no OEO conversion capability. For this purpose, the draft relies on control plan mechanism to provide required OAM functions. Specifically the proposed solutions are based on Link Management Protocol (LMP) [RFC4204] and RSVP-TE [RFC3209], [RFC3473] and do not require any extension to the data plan. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Multicast Traffic Measurement with IPFIX/PSAMP", Atsushi Kobayashi, Haruhiko Nishida, 25-Feb-08, The demand for streaming services is increasing because of the growing number of broadband users. In particular, multicast services might become core network services, and additional demand is expected. On the other hand, multicast operation is quite complex, and there are strict network quality requirements about packet loss and delay. A measurement system using IPFIX/PSAMP helps to monitor multicast traffic behavior carefully. However, some problems with IPFIX/PSAMP still remain when network operators try to introduce the measurement system. This document describes issues that the multicast traffic measurement system might encounter. The results are intended to be used to define multicast handling by IPFIX/PSAMP metering devices more clearly. "Updating RFC 3484 for multihoming support", Marcelo Bagnulo, 13-Nov-07, This note describes the limitations of RFC 3484 in multihomed environments and proposes possible updates to the default address selection mechanisms in order to cope with the identified limitations. "GMPLS MIB family update", Tomohiro Otani, Masanori Miyazawa, 13-Nov-07, This memo describes the necessity of generalized multi-protocol label switching (GMPLS) management information base (MIB) family update. Since the establishment of basic GMPLS protocol specifications, additional functionalities has been proposed and standardized so far, such as recovery, call support, optical transport network (OTN) support and so forth. Coinciding with these additional specifications, GMPLS MIB family is also desired to be updated to manage GMPLS networks appropriately. This document is to clarify missing pieces in currently defined GMPLS MIB family due to the enhancement of original GMPLS protocols. "Security Requirements for HTTP", Robert Sayre, 13-Nov-07, 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. "Authenticated Encryption with AES-CBC and HMAC-SHA1 (and other generic combinations of ciphers and MACs)", David McGrew, 13-Nov-07, 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. 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. "Distributed NAT for broadband deployments post IPv4 exhaustion", Alain Durand, 23-Feb-08, The common thinking for the last 10+ years has been to say that dual stack was the answer to IPv6 transition and that most things would be converted to dual stack way before we ran out of IPv4. Well, it has not happened. We are going to run out of IPv4 addresses soon, way before any significant IPv6 deployment will have occured. However, the quasi totality of the Internet and most of the computers in the home are still IPv4-only. Several distributed NAT architectures, based on different possible flavors of a carrier-grade NAT, are presented as solutions to maintain some form of connectivity between those home environments and the legacy Internet. "LISP Alternative Topology (LISP-ALT)", Dino Farinacci, 15-Nov-07, 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 Virtual Private Networks", Rahul Aggarwal, 13-Nov-07, 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. "Using ICE to establish SIP Dialogs", Bruce Lowekamp, David Bryan, 13-Nov-07, This draft explores a way SIP can be extended to allow a new dialog directly between the endpoints to replace an initial dialog that had one or more proxies in the signalling path. This technique relies on ICE to perform hole punching that allows a direct connection to be used in deployments where a sip-outbound proxy or SBC is used to establish SIP connections across NAT or firewall boundaries. It can also be used to replace such a dialog with a secure connection directly between the endpoints. This technique can be applied to traditional proxy-based SIP routing as well as to emerging P2PSIP deployments that lack centrally located proxies. This draft describes early work that evolved from ideas initially developed for P2PSIP that are no longer being pursued. We are interested in feedback on whether there is broader interest in these techniques. "VPLS OAM", Dinesh Mohan, 13-Nov-07, 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", Kenji Kumaki, Tomoki Murai, 13-Nov-07, 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 across ASes. In such a scenario, 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. "Integration of 6LoWPAN into IP networks", Derya Cansever, 13-Nov-07, The IETF 6LoWPAN working group was formed in 2004 to address the challenge of enabling wireless IPv6 communication over the newly standardized IEEE 802.15.4 low-power radio for devices with limited space, power and memory, such as sensor nodes [3]. IEEE 802.15.4 radio links, coupled with the interoperability and ubiquity of IP, will lead to exciting new deployment scenarios for these low-power networks. Sensor wireless networks will be integrated into wired and/or wireless fixed infrastructure. The integration of these sensor networks with the Internet and wireless infrastructure networks increases the network capacity, coverage area and application domains. In this draft we provide various integration scenarios and discuss associated issues with such deployments. "Firewall Control for Public Access Networks (FCON)", Hesham Soliman, Greg Daley, Suresh Krishnan, 25-Feb-08, This document proposes a new mechanism that allows end nodes to signal its preferences for traffic filters to a firewall function in the network or to another node that controls the firewall function in the network. "RTP Payload Format for MVC Video", Ye-Kui Wang, Thomas Schierl, 27-Feb-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-Nov-07, 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, 13-Nov-07, This document describes the 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. "Camellia Counter mode and Camellia Counter with CBC Mac mode algorithms", Akihiro Kato, Masayuki Kanda, 19-Mar-08, This document describes the algorithms and test vectors of Camellia block cipher algorithm in Counter (CTR) mode and Counter with Cipher Block Chaining MAC (CCM) Mode. The purpose of this document is to make the Camellia-CTR and Camellia-CCM algorithm conveniently available to the Internet Community. "Light-weight Multicast Address Discovery Protocol", Beau Williamson, 13-Nov-07, Light-weight, multicast address discovery mechanisms that can be used by large scale client-server application deployments have been virtually non-existent in the past. This has resulted in many multicast client-server applications being deployed with "hard-coded" multicast addresses within the client workstations in order to provide "zero-configuration" operation of the application. Unfortunately, many of these hard-coded multicast addresses are often picked at random by the application developers resulting in multicast address collisions with other protocols/applications or conflicts with the multicast scoping plans of a network administrator. This document describes a "light-weight" multicast address discovery protocol that can be used by application clients to locate their nearest application server using well-known scope relative multicast addresses. Once located, the server can then communicate the multicast address(es) that have been configured on the server by the network administrator for use by the application. This permits applications be written to operate in a flexible "near-zero" configuration mode without having to use "hard-coded" addresses or rely on any other network service other than multicast and the existence of a nearby application server. "Dynamic Update of PW Parameters", Frederic JOUNAY, 13-Nov-07, This draft aims at providing a generic solution for updating PW characteristics (interface parameters, label) on-the-fly without service interruption. The document specifies a new generic PWE control protocol mechanism called the PW Update. A PW Update LDP sub-TLV is defined for that purpose. It defines the signaling extension and describes the procedures to dynamically update the PW parameters. A use case is provided for CESoPSN PWs. "IPv4/IPv6 Coexistence and Transition: Requirements for solutions", Marcelo Bagnulo, Fred Baker, 20-Feb-08, This note presents the problem statement, analysis and requirements for solutions to IPv4/IPv6 coexistence and eventual transition in a scenario in which dual stack operation is not the norm. "A Session Description Protocol (SDP) Control Package Attribute", Chris Boulton, 22-Feb-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. "Architecture for IPv6 Communication over IEEE 802.15.4 subnetworks using 6LoWPAN", Dave Cullerot, 13-Nov-07, This document describes the architecture incorporating IEEE 802.15.4 subnetworks utilizing the 6LoWPAN adaptation layer into the family of Internet standards. "Source Address Selection Just by Routing Information for IPv6", Fujikawa Kenji, 25-Feb-08, This document describes a problem of source address selection Rule 8. stated in RFC3484[RFC3484], and shows one solution, which is based just on the destination based address routing and does not require policy routing such as source address based routing. "Application Conventions for Bundle-based Communications", Joerg Ott, 13-Nov-07, This document discusses issues arising when moving the bundle protocol usage from closed or lab deployments into open, heterogeneous environments with a variety of usages and applications carried over common bundle agents. We address naming conventions and endpoint identifiers, content encapsulation, and on the identification of application contents. "RTP payload format for the ITU-T Embedded Variable Bit-Rate speech/audio codec", Ari Lakaniemi, 13-Nov-07, This document specifies the Real-Time Transport Protocol (RTP) payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/audio codec. A media type registration for this RTP payload format is also included. "IS-IS Detailed IP Reachability Extension", Clarence Filsfils, 25-Feb-08, This document defines a means for IS-IS to carry detailed host reachability information along with summarized IP reachability. In particular it defines a new sub-TLV of the extended IP reachability TLV. "Service Provider Requirements for Ethernet control with GMPLS", Wataru Imajuku, 20-Nov-07, 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. "Providing guidance for Session Initiation Protocol (SIP) services", Arnaud Ligot, Thomas Froment, 22-Feb-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. "Managing Client Voice Peering Provisioning", David Schwartz, 13-Nov-07, This document describes the type of data provisioned among Voice Service Providers. This is in support of the service provider peering as defined by the Speermint WG. "NETCONF Configuration Interface Advertisement with WSDL and XSD", Hideki Okita, Iijima Tomoyuki, Yoshifumi Atarashi, 10-Mar-08, This memo describes a configuration interface advertisement method for NETCONF device developers. In the proposal, the developers take a configuration interface definition information of target NETCONF devices. On their development environment, they generate stab classes to control the devices. The NETCONF device advertises their configuration interface by a WSDL file. The WSDL file describes message type of each NETCONF operation of the device. The WSDL file contains XML Schema in its types element and describes definition of the types definition used to configuration data. By this configuration interface advertisement, Network management System (NMS) developers can improve their development efficiency of the NMS. "IGP Routing Protocol Extensions for Discovery of Upstream Label Assignment Node Capability", Yannick Brehon, Martin Vigoureux, Laurent Ciavaglia, Mohamad Chaitou, Zafar Ali, 19-Nov-07, This document proposes an extension to [TE-NODE-CAP] in order to support additional TE node capabilities in the context of Point-to- MultiPoint (P2MP) LSP routing and fast reroute protection. As for point-to-point LSP, nesting P2MP LSPs, i.e., MPLS P2MP hierarchy, is a desirable traffic-engineering feature. However, nesting P2MP LSPs requires a mechanism to coordinate the label allocation of the inner P2MP LSP between the egress nodes of the P2MP Tunnel as described in [MPLS-UPSTREAM]. To solve this issue, a new label allocation scheme called Upstream Label Assignment (ULA) is defined. Network elements responsible for the route computation of P2MP LSP should be aware of the nodes that support this functionality. For that purpose, we define a new bit flag to the TE Node Capability Descriptor as defined in [TE-NODE-CAP]. The bit flag (U) enables a node to advertise its capability to accept Upstream Label Assignment. "CLIENTID extension to the IMAP Protocol", Zoltan Oerdoegh, 13-Nov-07, This document describes the CLIENTID extension to IMAP. IMAP CLIENTID allows an IMAP client to identify itself to the IMAP server, which allows the IMAP server to store data specific to an individual IMAP client. The solution includes two new mechanisms. One to request a new Client-ID, and another to disclose the Client-ID to the IMAP server, which in turn initializes the client environment. "Deriving Fast Handover Key from MSK to secure the FMIPv6 signaling", Chunqiang Li, 21-Feb-08, This specification introduces a symmetric cryptography mechanism for protecting signaling messages between the Mobile Node and previous Access Router for Fast Mobile IPv6. The method defined here utilizes the Master Session Key(MSK) generated from EAP authentication to derive a fast handover key between the Mobile Node and the Access Router in order to avoid certain attacks. This mechanism also adopts the Mobile Node Identifier option and the mobility message authentication option to the FMIPv6 signaling messages. "Service Identfiers List Option for DHCPv6", Hui Deng, 15-Nov-07, 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, 22-Feb-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 verification mechanism that the home agent would use in order to verify the care-of addresses for the mobile node before using them for packet routing. "PIM Refresh Reduction Problem Statement", Mike McBride, 19-Nov-07, The PIM Working Group has a PIM refresh reduction charter goal. The solution to this goal will help reduce the periodic join/prune processing in PIM. The L3VPN Working Group identified this periodic messaging of PIM as a potential scaling problem for PIM based MVPNs. This document identifies the issues we are trying to solve with PIM refresh reduction. "Test Cases for the use of Galois/Counter Mode (GCM) and Galois Message Authentication Code (GMAC) in IPsec ESP", David McGrew, 16-Nov-07, This note provides test cases for the use of AES GCM and GMAC in ESP, as defined in RFC4106 and RFC4543, and clarifies some points in the latter specification. "The proposal of extenting RFC4666 for the M3UA deployment", Xu Chen, 16-Nov-07, RFC 4666 defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Some parts of the specification are unclear that may lead to misinterpretations that may impair interoperability between different implementations. RFC 4666 doesn't define the application of IPSTP-IPSEP interface. For the signalling network management function, messages and procedures, it needs more contributes. This document provides clarifications and amendments to RFC 4666. "The proposal of revision to procedure description in RFC4165", Xu Chen, 16-Nov-07, According to the conclusion of problem statement for RFC4165, an amendment of M2PA is needed. This document gives the suggested list of the contents to be revised and supplemented describes the reason to change and supplement ,and provides a proposal for revision. "PCN Boundary Node Behaviour", Tina Tsou, Tom Taylor, 19-Nov-07, The Pre-Congestion Notification Architecture document defines a PCN domain and the PCN-ingress and PCN-egress nodes that form its boundary. The present document is an attempt to describe the detailed behaviour of the PCN boundary nodes. It is a contribution toward the PCN WG milestone: "Suggested Flow Admission and Termination Boundary Mechanisms". This first version is expected to evolve with discussion and further thought toward a more precise and prescriptive view of boundary node behaviour. "Verbal Key Exchange", Pars Mutaf, 19-Dec-07, This document describes a verbal key exchange protocol in which a short fingerprint is used to represent a "one-time" public key fingerprint. The one-time public key is immediately used for key exchange, before an attacker has time to find a public/private key pair that gives the same fingerprint and mount a Man-in-the-Middle attack. The protocol, however, requires that both users be present for fingerprint verification, making it suitable for mobile users only. "PIM Based MVPN Deployment Recommendations", Mike McBride, 22-Feb-08, Multicast VPN, based on pre-standard drafts, has been in operation in production networks for many years. This document describes some of the practices and experiences gained from implementation and deployment of MVPN using PIM with GRE tunnels. It is informational only. "Name Server Control Protocol", Roy Arends, 20-Nov-07, This document describes the Name Server Control Protocol (NSCP). The NSCP will permit the management of diverse name server implementations. The NSCP uses NETCONF as framework. "An Explicit Signaling Target Message Routing Method (EST-MRM) for the General Internet Signaling Transport (GIST) Protocol", Roland Bless, 3-Dec-07, 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, 12-Mar-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. "Ogg Media Types", Ivo Goncalves, Silvia Pfeiffer, Christopher Montgomery, 8-Apr-08, This document describes the registration of media types for the Ogg container format and conformance requirements for implementations of these types. "Roaming Mechanism between PMIPv6 Domains", Jee-Hyeon Na, Soochang Park, Jung-Mo Moon, Sangho Lee, Euisin Lee, Sang-Ha Kim, 3-Dec-07, Proxy Mobile IPv6 (PMIPv6) is designed to provide mobility service to mobile nodes in the network domain that does not require the nodes to be involved in mobility management. In other words, the PMIPv6 can support roaming within a PMIPv6 domain, i.e. intra-domain roaming, transparent to mobile nodes without mobility functionality. However, the mobile nodes should have additional protocols such as MIPv6 for roaming between PMIPv6 domains, i.e. inter-domain roaming, although the domains also service the transparent mobility. Hence, network- based solution is needed for providing transparent mobility to the mobile nodes that only move about between PMIPv6 domains. This document specifies the inter-domain roaming mechanism controlled by the networks adopting the PMIPv6 protocol. "Notes on IETF Rough Consensus", Lisa Dusseault, 3-Dec-07, The IETF makes decisions using what we refer to as rough consensus, using a great deal of flexibility and judgement depending on the situation. This document documents various approaches to determining rough consensus. "The Komondor Peer to Peer Security System", Zoltan Czirkos, Gabor Hosszu, 4-Dec-07, This memo presents Komondor, an experimental peer-to-peer security system. Komondor is a network intrusion detection system. Hosts running this software organize themselves automatically in an overlay network, where they share information about intrusion attempts they detect. This way the security of all participants is increased, as they are able to prepare for some of the attacks in advance. The overlay created is a peer-to-peer network, which is completely decentralized. This communication model ensures stability, and by using this the system remains operational over an unstable network. "DHCP Fragmentation and Reassembly", Fred Templin, 4-Dec-07, 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 ability to adjust their message sizes to avoid IP fragmentation, however no such capability is built into the UDP transport. UDP applications must therefore have a means to perform their own fragmentation and reassembly prior to submitting their data to UDP/IP. This document specifies a fragmentation/reassembly capability for DHCP. "An overload control package for the Session Initiation Protocol (SIP).", Youssef Chadli, Xavier Marjou, 4-Dec-07, 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 an 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. "V5 Level two and three Over IP", Quoc Chinh Nguyen, 4-Dec-07, This document proposes the use TCP/IP as the transport protocol for V5. The migration from the current trunk 2048 kbps physical to an IP based transport will reduce the cost associated with dedicated trunk based link. Also, the current signaling End-to-End will be unchanged to make the transition seamless as possible. "P2PSIP Clients", Victor Pascual, Marchin Matuszewski, Eunsoo Shim, Hewen Zhang, Song Yongchao, 25-Feb-08, This document describes why and when some devices would better be a Client rather than a Peer. The purpose of this document is to facilitate the discussion and understanding about the Client node type. "Urban WSNs Routing Requirements in Low Power and Lossy Networks", Mischa Dohler, Giyyarpuram Madhusudan, Gabriel Chegaray, Thomas Watteyne, Christian Jacquenet, 5-Dec-07, The application specific routing requirements for Urban Low Power and Lossy Networks (U-L2Ns) 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 citizens' 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 - requires the use of suitable multi-hop 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 outdoors urban application scenario. As such, for a wireless RL2N solution to be competitive with other incumbent and emerging solutions, the protocol ought to be energy-efficient, scalable and autonomous. This documents aims to specify a set of requirements reflecting these and further U-L2Ns tailored characteristics. "RSA AES-SIV Ciphersuites for TLS", Dan Harkins, 5-Dec-07, This memo describes two new ciphersuites for the Transport Layer Security (TLS) protocol using the Advanced Encryption Standard (AES) in Synthetic IV (SIV) mode. SIV provides authenticated encryption with associated data (AEAD) and, unlike other AEAD cipher modes, provides resistance to nonce misuse. "UDP Traceroute Message Extension", Naiming Shen, Carlos Pignataro, Rajiv Asati, Enke Chen, 6-Dec-07, 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, 7-Dec-07, 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. "IPv6 Prefix Delegation routing state maintenance approaches", Markus Stenberg, Ole Troan, 10-Dec-07, The maintenance of Prefix Delegation (PD) routing state is an issue that people have discussed in the IETF DHC WG, and there have been drafts on the topic. However, as the pros and cons of the different routing state maintenance solutions have not been examined thoroughly, this text attempts to shed some light on both the actual problem and the various alternative solutions. "Using HMAC-authenticated Encryption in the Cryptographic Message Syntax (CMS)", Peter Gutmann, 10-Dec-07, This document specifies the conventions for using HMAC-authenticated encryption with the Cryptographic Message Syntax (CMS) authenticated- enveloped-data content type. This mirrors the use of HMAC combined with an encryption algorithm that's already employed in IPsec, SSL/ TLS, and SSH, which is widely supported in existing crypto libraries and hardware, and has been extensively analysed by the crypto community. "DNS Extension for ENUM Source-URI", Hadriel Kaplan, Robert Walter, Raja Gopal, Tom Creighton, 11-Dec-07, This document defines a specific DNS extension, based on the EDNS0 OPT RR, for an ENUM query to include the source URI which caused the ENUM request. This is useful, for example, to specify the originating SIP or TEL URI from a SIP request which triggered the ENUM query, so the ENUM server can provide a different response. "NSDB Protocol for Federated Filesystems", Renu Tewari, Manoj Naik, Daniel Ellard, Craig Everhart, 9-Jan-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. "Diagnose P2PSIP Overlay Network Failures", Song Yongchao, Hewen Zhang, XingFeng Jiang, 24-Feb-08, This document describes a simple and efficient mechanism that can be used to detect and localize failures in P2PSIP overlay network. This document mainly consists of two parts: information carried in a P2PSIP Peer "Echo request" message and "Echo response" message for the purpose of fault detection and localization, and mechanisms for processing those messages. "P2PSIP Client Protocol", Song Yongchao, XingFeng Jiang, Hewen Zhang, Hui Deng, 23-Feb-08, This document defines P2PSIP client protocol, one protocol for client-peer communication, which is used to create, implement and maintain the services between a client and its associated peers. "SIP INFO Use Cases", Hadriel Kaplan, 25-Feb-08, This document lists several known and potential use cases for SIP INFO requests, as discussed on the SIP WG mailing list. The use cases were requested by the WG chairs at the SIP WG meeting in IETF 70, and are documented herein for the purpose of discussion only. "Interworking LISP with IPv4 and IPv6", Darrel Lewis, 14-Dec-07, This document describes various methods for interworking between the Internet and an Internet in which Endpoint Identifiers are separated from to Routing Locators using the Locator/ID Separation Protocol (LISP). Existing Internet hosts that do not participate in the LISP system must still be able to reach sites numbered from this EID prefixes. This new draft describes mechanisms which might be used to provide reachability between these types of sites. A new network element, the Proxy Tunnel Router may also be deployed to act as a transitional LISP Ingress Tunnel Router for a subnetwork which does not implement LISP but which requires communication to devices that are addressed from LISP prefixes. "Clearance and CA Clearance Constraints Certificate Extensions", Sean Turner, Santosh Chokhani, 14-Dec-07, This document defines the syntax and semantics for the Clearance and the Certification Authority (CA) Clearance Constraints X.509 certificate extensions. The Clearance certificate extension is used to indicate the clearance held by the subject. The CA Clearance Constraints certificate extension values in a Trust Anchor (TA) and the CAs in a certification path constrain the effective Clearance of the subject of the last certificate in the certification path. "Different types of nodes in P2PSIP", Yao Wang, 14-Dec-07, This document is an attempt to classify different types of node in peer-to-peer Session Initiation Protocol (P2PSIP). Four possible types of nodes in P2PSIP are discussed based on two characters: whether it offers overlay-routing services and whether it offers storage functions. The behaviors of each type of nodes and their possible necessities are analyzed. This document is dedicated to be a reference for clarifying some controversial terms in P2PSIP working group, such as "client", "low-function peer", etc. "Handover management scheme for different IP WLAN subnets", Shigeru Kashihara, 17-Dec-07, This document discusses handover management scheme for WLAN handover across different IP subnets. To achieve seamless handover, the following three requirements should be satisfied. (I) prompt and reliable detection of degradation in wireless link quality, (II) elimination of handover processing delay on layer 2 and 3, (III) selection of a better WLAN. We then describe our proposed handover management scheme satisfying these requirements, and explain an architecture design and implementation for our proposed scheme. "RTP Payload Format for SPIRIT IP-MR Speech Codec Software", Andrey Setsko, 20-Feb-08, This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload, introduced redundancy for robustness against packet loss, and payload format extension for future versions compatibility. "FIQL: The Feed Item Query Language", Mark Nottingham, 18-Dec-07, The Feed Item Query Language is a simple but flexible, URI-friendly syntax for expressing filters across the entries in a Web feed. It also specifies a mechanism to allow feeds to indicate what types of queries are supported. "An elliptic curve based authenticated key agreement protocol for managing wiress handover security", Changsheng Wan, Aiqun Hu, 18-Dec-07, The roaming of a lot of mobile nodes from one authenticator to another may put a heavy burden on the authentication server. This paper proposes an elliptic curve based key agreement protocol with authentication property to address this problem. "Duplicate a SIP session", Pierre Imai, Bernd Lamparter, Paulo Loureiro, 19-Dec-07, Session duplication copies media of an ongoing communication session from one device to another. After duplication the two devices have independent control over this media. This is in particular useful for one-way media like broadcast IPTV or Video-on-Demand. This document describes the general methods and specifies the signaling and media flows for providing this service using the Session Initiation Protocol (SIP). "Specifying Location Quality Constraints in Location Protocols", Martin Thomson, James Winterbottom, 20-Dec-07, Table of Contents "HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment", Gonzalo Camarillo, Pekka Nikander, Jani Hautakorpi, 16-Feb-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. "Key Management Mobility Capability (K) flag in Mobile IPv6 BU/BA messages.", Sebastien Decugis, 21-Dec-07, Mobile IPv6 specification (RFC 3775) introduces a flag called "Key Management Mobility Capability (K)" to use during the home registration procedure (BU/BA exchange.) This document describes the sequences of events that occur when this flag is not used by the implementation. It also highlights the requirements that this flag puts on the interface between the MIPv6 entity and the IKE entity. "Other Certificates Extension", Stephen Farrell, 4-Apr-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. "Translator specification approach", Hiroshi Miyata, 23-Dec-07, IPv4 address is estimated to run out shortly. So as [I-D.durand-v6ops-natv4v6v4] stated, we have to consider IPv6 only node for smooth transition. On the other hand, IETF have deprecated the NAT-PT with some reasons. And now we need to seek alternative solutions. Before talking specific technology, we need to consider overall strategy for translation technology. "Retriving MIB Information based on NGI", JinXiang Zhang, 31-Dec-07, 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, 1-Jan-08, This document defines additional Layer 2 Tunneling Protocol (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. "Traffic visibility using IPsec ESP NULL encryption", Ken Grewal, 3-Jan-08, This document describes leveraging UDP encapsulation for IPsec, using ESP NULL encryption in order for intermediary devices to inspect the IPsec packets. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. "Text media handling in RTP based real-time and message conferences", Gunnar Hellstrom, Arnoud Wijk, 3-Jan-08, This memo specifies methods for text media handling in multi-party calls, where the text is carried by the RTP protocol. Real-time text is carried in a time-sampled mode according to RFC 4103. Centralized multi-party handling of real-time text is achieved through a media control unit coordinating multiple RTP text streams into one RTP session, identifying each stream with its own SSRC. Identification for the streams are provided through the RTCP messages. This mechanism enables the receiving application to present the received real-time text medium in different ways according to user preferences. Some presentation related features are also described explaining suitable variations of transmission and presentation of text. Call control features are described for the SIP environment, while the transport mechanisms should be suitable for any IP based call control environment using RTP transport. "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 4-Jan-08, As a foundation for the definition of application-specific, bi- directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions. "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 4-Jan-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): Instant Messaging", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 4-Jan-08, This document defines a bi-directional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Text Chat", Peter Saint-Andre, Eddy Gavita, Nazin Hossain, Salvatore Loreto, 4-Jan-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). "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions", Peter Saint-Andre, 4-Jan-08, This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP) and those that implement the Session Initiation Protocol (SIP). "On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship", Wassim Haddad, Mats Naslund, 6-Jan-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, 6-Jan-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. "Requirements for Federated File Systems", Daniel Ellard, Craig Everhart, Renu Tewari, Manoj Naik, 21-Mar-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. "Kerberos V5 Internationalization of Error Messages", Simon Josefsson, 9-Jan-08, This document describes an internationalization extension for the Kerberos V5 protocol. The extension allows error messages to be sent in the users' language. "Coding and transmission of text in real-time and en-bloc mode based on MSRP", Gunnar Hellstrom, Paul Jones, Gregg Vanderheiden, 9-Jan-08, This memo describes conventions for exchange and presentation of text in SIP sessions through the Message Session Relay Protocol MSRP. It covers two different methods for taking the initiative to transmit. These methods are timer initiated real-time text and user requested en-bloc transmission in Messaging. The document gives specific guidance on handling of text presentation and presentation control of conversational sessions. It specifies how the capability to conduct MSRP sessions with real-time text is declared so that session negotiation can make decisions on what transport protocol to use and how to route the calls to get the desired support for text communication. "Syntax for binding documents with time stamps", Adriano Santoni, 19-Mar-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 September 14, 2008 [page 1] Internet-Draft timestampeddata March 2008 This document proposes a simple syntax based on the Cryptographic Message Syntax (RFC 3852). "Target URI delivery in the Session Initiation Protocol (SIP)", Christer Holmberg, Hans Erik van Elburg, 16-Jan-08, This document specifies an alternative mechanism how to deliver the current target URI to the UAS, e.g. in order to implement the use- cases specified in draft-rosenberg-sip-ua-loose-route-01 [8]. "The RObust Header Compression (ROHC) Framework", Kristofer Sandlund, Ghyslain Pelletier, Lars-Erik Jonsson, 11-Jan-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. "A WebDAV Search Grammar for XML Properties", Roberto Javier Godoy, Hugo Minni, 25-Feb-08, This document specifies xml-search, a search grammar for use with the Web Distributed Authoring and Versioning (WebDAV) SEARCH protocol. It extends the DAV:basicsearch grammar with XPath expressions that are evaluated on resources' properties whose values are XML fragments. The full expression power of XPath may exceed the requirement in simple use cases; therefore, some provisions are made in order to reduce the computational cost of evaluating allowed queries. "SNMP Trace Analysis Definitions", University Twente, Aiko Pras, Matus Harvan, 24-Feb-08, The Network Management Research Group (NMRG) started an activity to collect traces of the Simple Network Management Protocol (SNMP) from operational networks. To analyze these traces, it is necessary to split potentially large traces into more manageable pieces that make it easier to deal with large data sets and simplify the analysis of the data. This document provides some common definitions that have been found useful for implementing tools to support trace analysis. This document mainly serves as a reference for the definitions underlying these tools and it is not meant to explain all the motivation and reasoning behind the definitions. Some of this background information can be found in other research papers. "LDP extension for AII reachability", Simon DeLord, 15-Jan-08, The dynamic End-to-End Multisegment pseudowire setup requires PEs to maintain a pseudowire routing table when using FEC129. There is therefore a requirement for automatic Attachment Individual Identifiers discovery. Two mechanisms already exist, a BGP based solution and an IGP based one. Here we define a third solution relying on LDP. It allows for automatic discovery when a PE does not run BGP or IGP. The mechanism described here only runs on the on the T-LDP (Targeted LDP) session between the T-PE and S-PE, but not on any other LDP session which may exist for the tunnels. The T-PE advertises its locally attached AIIs only for the S-PE to build its PW routing table (the S-PE does not propagate this information further via this mechanism). The mechanism described here is intended to complement and interwork with other existing autodiscovery and routing mechanisms already described with BGP and OSPF. "Additional Key words to Indicate Requirement Levels", Paul Hoffman, 15-Jan-08, Some document authors want to express requirement levels using the traditional definitions of "MUST" and "SHOULD" from RFC 2119, but also want to express that there is an expectation that later versions of the document may change those requirements. For example, they may want to express "this SHOULD be implemented now, but we expect that this will become a MUST requirement in a future update to this standard". This document defines three new keywords, "MUST-", "SHOULD+", and "SHOULD-" to facilitate such definitions. "Extensible Supply-chain Discovery Service Problem Statement", , 25-Feb-08, This document discusses the requirements of an application layer protocol which can meet the needs of today's complex and dynamic supply chains. Currently, supply chain communication traffic travels over the Internet using existing Internet protocols, such as FTP, SMTP, and DNS. This is a temporary solution for a growing niche. This document elaborates on issues that would arise if this trend continues. Also, this document outlines a set of design concerns that an application layer protocol needs to address in order to be deployable in a real-world supply chain. This document obsoletes "Extensible Supply-chain Discovery Service Problem Statement draft-rezafard-esds-problem-statement-00". Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). "An IPv6 Geographic", Tony Hain, 16-Jan-08, This document defines an IPv6 Geographic global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [1] and the "IPv6 Addressing Architecture" [2]. It is designed to facilitate scalable Internet routing when sites attach to multiple service providers, by using a prefix based on a geographic reference to the site. A natural byproduct of this address allocation mechanism is that all addresses are fixed allowing sites to change providers at will without requiring their network to renumber. "Issues of the Key Management Mobility Capability (K) flag in Mobile IPv6.", Sebastien Decugis, 16-Jan-08, Mobile IPv6 specification (RFC 3775) introduces a flag called "Key Management Mobility Capability (K)" that is used during home registration procedure. This document describes the behavior of implementations when the capability is supported or not. The purpose of this description is to highlight the expected behavior of implementations at the end of home registration process with regards to the exchanged (K) flag value. "SIP Usage Scenarios Similar to SPIT", Dan York, 16-Jan-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. "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", Paul Hoffman, 19-Feb-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. "What is Next Steps in Signaling anyway - A User's Guide to the NSIS Protocol Family", Jukka Manner, Roland Bless, 18-Jan-08, The Next Steps in Signaling (NSIS) Working group was officially formed in November 2001 to standardize a new IP signaling protocol suite. Six years have now passed and the first actual protocol specifications have been finalized. The purpose of this draft is to give an overview of what has been achieved, how the industry can make use of the new protocols, and how the research community can further extend the designs. "vCard Format Specification", Pete Resnick, Simon Perreault, 7-Feb-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.). "G.729.1 RTP Payload Format update: DTX support", Aurelien Sollaud, 21-Jan-08, This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) 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. "ALM API for Topology Management and Network Layer Transparent Multimedia Transport", Boon Ping Lim, K Ettikan, 21-Jan-08, This document defines and describes the topology management and network layer transparent middleware wrapper API for ALM forwarding table construction, distribution and multimedia transport over IPv4/IPv6 for unicast and xcast. "multilingual/multiscript country code tags http://mltf.org/draft-mltf-jfcm-cctags-01.txt", Jean-Francois Morfin, 24-Feb-08, This memo documents the multilingual and multiscript country code tags that are derived from ISO 3166-1:2006, and their extension from other tables and standards, which can be used in applications, protocols, BCP 47 langtags, databases, etc. in order to index, reference, or sort country oriented information that is expressed in any mode and language. "Digital Signatures on Internet-Draft Documents", Russ Housley, 10-Apr-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. "Hierarchical Networking and IPv6", Shyam Bandyopadhyay, 23-Jan-08, This document tries to address an approach for reorganization of entire network in a large address space. It describes how entire address space can be distributed within some regions and sub regions inside each of them by establishing mesh structured hierarchy. It addresses issues which could be relevant to this architecture in the context of IPv6. This document also tries to come out with an approach how IP switch based network can perform as good as ATM network for the processing of real time traffic. "End-to-End Security for DTLS-SRTP", Kai Fischer, 23-Jan-08, The end-to-end security properties of DTLS-SRTP depend on the authenticity of the certificate fingerprint exchanged in the signalling channel. In current approaches the authenticity is protected by SIP-Identity or SIP-Identity-Media. These types of signatures are broken if intermediaries like Session Border Controllers in other domains change specific information of the SIP header or the SIP body. The end-to-end security property between the originating and terminating domain is lost if these intermediaries re-sign the SIP message and create a new identity signature using their own domain credentials. This document defines a new signature type 'Fingerprint-Identity' which is exchanged in the signalling channel. Fingerprint-Identity covers only those elements of a SIP message necessary to authenticate the certificate fingerprint and to secure media end-to-end. It is independent from SIP-Identity and SIP-Identity-Media and can be applied in parallel to them. "Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging SRV Protocol Label registry for SIP/SIMPLE protocol.", Salvatore Loreto, 23-Jan-08, This document registers with the IANA a new Instant Messaging SRV Protocol Label registry for SIP/SIMPLE protocol as specified in Address Resolution for Instant Messaging and Presence. This SRV Protocol Label indicates SIP/SIMPLE protocol as a protocol that will be used to instantiate the instant messaging or presence operations. "Media Type Registration of GSM-HR payload Format", Rocky Wang, Ying Zhang, 24-Jan-08, This document registers a media type for the Real-time Transport protocol (RTP) payload format, which is used for the Group Special Mobile half-rate speech transcoding. "Discovery of CONVERT parameters", Alexey Melnikov, Peter Coates, 24-Jan-08, This is a companion document to the Lemonade CONVERT (draft-ietf-lemonade-convert-XX.txt) extension. It summarizes various proposals for CONVERT MIME type and conversion parameter discovery. "Mechanisms for use in pointing to overlay networks, nodes, or resources", Ted Hardie, 27-Jan-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. "DYNAMIC RPC NUMBER ASSIGNMENT AND DISTRIBUTION", Martin Rosenau, 28-Jan-08, The RPC port mapper described in [1] and [2] allows a service to bind to any free TCP or UDP port. A client that wants to establish a connection to a server will ask the RPC portmapper for the TCP or UDP port of the service and establish the connection. The problem is that clients now need to know the RPC application number of the service they want to connect to. These numbers are assigned by the IANA for registered applications. For "experimental" applications there is a range of application numbers that is managed by the local network's administrator. Especially when using such "experimental" applications in wide area networks there is the problem that the client needs to know the server application's RPC application number. The protocol described in this document allows a server host the dynamical assigning of RPC numbers. It allows clients to ask the server for for RPC number by the application name. "Requirements for a Configuration Data Modeling Language", Randy Presuhn, 15-Feb-08, This memo contains a compilation of requirements for a Configuration Data Modeling Language. Although focusing on the needs of the NETCONF Protocol, these requirements potentially have broader applicability. Comments should be sent to ngo@ietf.org. "NETCONF Data Modeling Language Requirements", Bernd Linowski, Martin Storch, Mehmet Ersue, Mikko Lahdensivu, 18-Feb-08, This document collects requirements for a Data Modeling Language (DML) and has been prepared as a contribution to the RCDML design team working on the "Requirements for a Configuration Data Modeling Language". Comments can be sent to ngo@ietf.org. "Analysis of Rendezvous Mechanism for Home Access Using SIP", Makoto Saito, Dan Wing, 29-Jan-08, Home servers are becoming more common and people expect to still access them even when they are outside their home. However, there are several requirements to realize remote access to the home such as name resolution, NAT/Firewall traversal, and authentication/ authorization. This document describes what technologies can be used to solve these issues and analyzes the utility of SIP as a rendezvous mechanism for this use case. "Common Practices in Routing Protocols Deployment", Russ White, John Burns, 12-Mar-08, This document discusses common practices used in deploying routing protocols in both public and private networks. The focus is not to describe how routing protocols should be deployed, but rather how they are generally deployed, to provide those working on specifications which impact the operation of routing protocols with guidance in what will likely be deployed, or what will likely not be deployed. The focus in thie document will be ionterdomain routing, but it will cover aspects of intradomain routing, as well.1. Background When considering new extensions to existing routing protocols, it's useful to consider them in the context of existing usage of these protocols. Various questions come to mind, such as: o Common Underlying Principles of Network Designs o Common Practices in Route Origination o Common Practices in Routing Database Management o Common Practices in Aggregation o Common Practices in Peering o Common Practices in Security o .... Each of these topics will be covered in a separate section below. "Connecting IPv6 Islands over IPv4 MPLS networks using IPv6 Provider Edge Routers (6PE-Alt)", Vishwas Manral, 30-Jan-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. The 6PE-Alt routers exchange the IPv6 reachability information transparently over the core using the Multi-Protocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE-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 tranport 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. "Administration Protocol for Federated Filesystems", Daniel Ellard, Craig Everhart, Renu Tewari, Manoj Naik, 31-Jan-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. "Simple PANA PAA Discovery Protocol", Victor Fajardo, 31-Jan-08, The PANA Base protocol defines a method for carrying EAP message exchanges over UDP/IP. This means that the PANA Client (PaC) is required to know the IP address of the PANA Authentication Agent (PAA). In many cases, this is not convinient or practical. This document proposes a simple PAA discovery scheme that allows the PaC to determine the PAA IP address without any modification to the base protocol messages or exchange sequence. "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", Nikos Mavrogiannopoulos, 31-Jan-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. "A Reliable Transport Mechanism for PIM", Dino Farinacci, IJsbrand Wijnands, 1-Feb-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. "sNAT-PT: Simplified Network Address Translation - Protocol Translation", Hiroshi Miyata, 1-Feb-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]. "DKIM Author Signing Practices (ASP)", Author Domain, Return Path, John Levine, Wietse Venema, 2-Feb-08, DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transport Agents (MTAs) or Mail User Agents (MUAs). The primary DKIM protocol is described in [RFC4871]. This document describes the records that authors can use to advertise their practices for signing their outgoing mail, and how other hosts can access those records. "P2PSIP Security Analysis and Evaluation", Song Yongchao, Ben Zhao, XingFeng Jiang, Jiang Haifeng, 4-Feb-08, This document provides an analysis and evaluation of security with P2PSIP overlay network. The draft compares security difference between C/S and P2P, then partitions the P2PSIP architecture into layers, and analyze the security issues in each layer and the security relationship among the layers. Security issues with different kind of application scenarios are distinct. This draft classifies the application scenarios into two main types, and the security threats with these two types of scenarios are analyzed in detail. "Shim6 Implementation Report : LinShim6", Sebastien Barre, 5-Feb-08, LinShim6 is an implementation of the Shim6 and REAP protocols, on the Linux platform. This draft provides a brief description of the architecture and describes the current state of our implementation. For each feature of the protocols, its level of support is described. Protocol conformance is evaluated against [1] and [2]. "Enhanced BGP Capabilities for Exchanging Second-best and Back-up Paths", Brian Dickson, 25-Feb-08, This Internet Draft describes an enhanced way to exchange prefix information, to permit multiple copies of a prefix with different paths to be announced and withdrawn. This negotiated capability provides faster local (inter-AS) and global (intra-AS) convergence, reduces path-hunting, improves route- reflector behaviour, including eliminating both persistent oscillations and BGP "wedgies". Additional prefix instances have new optional BGP attributes, to control path selection. Withdrawl of prefixes will require new attributes to disambiguate prefix instances. 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. "SIP E.164 Return Routability Check (RRC)", Dan Wing, 8-Feb-08, SIP lacks a mechanism to determine which domain can claim ownership of a certain telephone number. Due to this, it is impossible to establish meaningful identity or to authenticate endpoints that use telephone number URIs and domain names in their From address. This document proposes a solution to this problem using a return routability test. "Aggregation: Methods and Benefits, for IPv4, IPv6 or other binary addresses", Brian Dickson, 5-Feb-08, This Internet Draft discusses general benefits of aggregation, with quantitative examples of different aggregation strategies for the same set of allocations. Recommended "best practices" for service providers and enterprises are listed, as well as "how-to" information.Author's Note This Internet Draft is intended for Informational status, for v6ops or other suitable WG. "A Survey and Analysis of Address Allocation Strategies for IPv4 and IPv6", Brian Dickson, 5-Feb-08, This Internet Draft describes, analyzes, and compares different strategies for allocating addresses, in a way that can be generalized for any power-of-two sized, binary address space. One such strategy is proposed as being "optimal", when viewed from the perspective of space-packing efficiency. This Draft recommends use of this technique as a "Best Current Practice", for both IPv4 and IPv6 address allocations.Author's Note This Internet Draft is intended to result in this draft or a related draft(s) being placed on the Informational Track for v6ops. "IANA Guidelines for IPv4 Multicast Address Assignments", Michelle Cotton, Dave Meyer, 5-Feb-08, This memo provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. "Special Use IPv4 Addresses", Michelle Cotton, 6-Feb-08, This document 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. "Validation of Route Origin Authorizations in BGP using the Resource Certificate PKI", Geoff Huston, George Michaelson, 7-Feb-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. "Indicating Support for Basic Media Server Capabilities in the Session Initiation Protocol (SIP)", Chris Boulton, 7-Feb-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. "Hypertext Transfer Protocol (HTTP) Digest Authentication using Global System for Mobile Communications (GSM) A3 and A8", Brett Wallis, 7-Feb-08, This memo specifies a one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication based on Global System for Mobile Communications (GSM) authentication and key generation functions A3 and A8. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication session key distribution in GSM and Universal Mobile Telecommunications System (UMTS) networks. A3-A8 is a challenge-response based mechanism that uses symmetric cryptography. "LoWPAN simple fragment Recovery", Pascal Thubert, 7-Feb-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. "EAP Authentication Using Only A Password", Dan Harkins, Glen Zorn, 25-Feb-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. "NS Zone Transfer Protocol (AXFR)over the User Datagram Protocol (UDP)", Edward Lewis, 8-Feb-08, The Domain Name System's Authoritative Transfer (AXFR) use of the User Datagram Protocol (UDP) as a transport protocol is defined. "IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", Remi Despres, 9-Feb-08, IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly deploy IPv6 unicast service to its existing IPv4 sites. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, 6rd requires a service provider to use one of its own IP prefixes rather than the fixed 6to4 prefix. A service provider has used this mechanism for its own "rapid deployment" of IPv6 (five weeks from first exposure to "opt-in" deployment for 1,500,000 residential sites). "PMIPv6 Route Optimization Protocol", Behcet Sarikaya, Xia Qin, Andy Huang, Wenson Wu, 11-Feb-08, This document defines route optimization protocol for Proxy Mobile IPv6. Proxy home test, concurrent proxy care-of test and handover procedures based on Enhanced Route Optimization for Mobile IPv6 are explained. Mobile access gateway uses cryptographically generated home addresses so that no more home test is needed after the initial home test. Handover home keygen token is used during handover in order to eliminate home test for the next mobile access gateway. The protocol also supports IPv4 transport network operation. "IMAP Response Codes", Arnt Gulbrandsen, 15-Feb-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]. "Consolidated Provisioning Problem Statement", David Schwartz, Rohan Mahy, Alan Duric, Edward Lewis, 11-Feb-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. "Probabilistic Routing Protocol for Intermittently Connected Networks", Anders Lindgren, Avri Doria, 11-Feb-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", Fred Templin, 6-Apr-08, Subnetworks are connected network regions bounded by border routers that forward unicast and multicast packets over a virtual topology manifested by tunneling. This virtual topology resembles a "virtual ethernet" link, but may span multiple IP- and/or sub-IP layer forwarding hops that can introduce packet duplication and/or traverse 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. "Consolidated Provisioning Problem Statement", David Schwartz, Rohan Mahy, Alan Duric, Edward Lewis, 11-Feb-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. "XCAST6 (version 2.0) Protocol Specification", Yuji Imai, Takahiro Kurosawa, Nobuo Kawaguchi, Eiichi Muramoto, 11-Feb-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. "UDP and TCP as the New Waist of the Internet Hourglass", Jonathan Rosenberg, 11-Feb-08, One of the fundamental design principles of the Internet is that IP represents a common intermediate protocol layer, linking together a variety of link layer technologies underneath with a large number of applications on top. When drawn graphically, this can be show as an hourglass with IP in the middle. The preponderence of NATs and firewalls in the Internet has changed this reality, such that UDP and TCP are now the waist of the hourglass. This document discusses this change and describes its implications for protocol and application design. "Overview of Existing Routing Protocols for Low Power and Lossy Networks", JP Vasseur, 12-Feb-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. Such low power and lossy networks (L2Ns) have routing 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 L2Ns. It provides guidance on how lessons from existing and prior efforts can be leveraged in future protocol design. "Specification of 3GPP IM CN Subsystem XML body handling", John-Luc Bakker, 12-Feb-08, This document registers new disposition-types for the Content- Disposition header that apply to the application/3gpp-ims+xml body used by 3GPP, since Release 5. 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 Session Initiation Protocol (SIP)", Lorenzo Miniero, Alessandro Amirante, Tobia Castaldi, Simon Romano, 12-Feb-08, This document defines a Session Initiation Protocol (SIP) Control 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 SIP Control Framework. "Terminology for Network-based Localized Mobility Management", Suresh Leroy, Zachary Zeltsan, 12-Feb-08, This document provides a glossary of the terms related to Network- based Localized Mobility Management (NETLMM). The document lists the definitions of the terms introduced in the Internet Drafts and RFCs created by the NETLMM working group. It also provides the expansions of the acronyms that are used in the group's documents. "Mobile IPv6 Home Link Operation over SDO point-to-point links", Vijay Devarapalli, Nishi Kant, Heeseon Lim, 24-Feb-08, The Mobile IPv6 protocol is being adopted by various Standards Development Organizations (SDO) for mobility across wide area networks. Some of the architectures developed by these SDOs require some of the access links to be home link for mobile node. The belief is that if the mobile node thinks it is attached to the home link, there will not be additional packet overhead due to Mobile IPv6 tunneling. Many of these links where the mobile node is supposed to be attached to the home link are point-to-point links. There are some issues with making these point-to-point links appear like home link to the mobile node. This document captures some of the issues related to this, and analyzes possible solutions. "Enabling an Enhanced Care-of Address Reachability Test for the Home Agent", Wassim Haddad, Francis Dupont, 25-Feb-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. "CPE Default Route Detection", Gunter Van de Velde, John Jason Brzozowski, Shin Miyakawa, 13-Feb-08, When the CPE (Customer Premisses Equipment) device is a routed IPv6 device, then detection automation of the upstream connectivity (i.e. the default-route) has not been uniformly described. There are many CPE vendors, and they may have many technologies to achieve this goal. This document provides an overview of the problem space, while identifying various options within the solution space. "PIM Group-to-RP Mapping", Bharat Joshi, Andy Kessler, David McWalter, 13-Feb-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. "Redirecting Proxy Binding Updates in PMIPv6", Suresh Krishnan, Samy Touati, Zu Qiang, 25-Feb-08, This document specifies a new LMA Redirect mechanism, where an initially contacted LMA can let the MAG know that it needs to connect to an alternate LMA to get mobility services, either for overload prevention and/or load balancing purposes. This document proposes a new error code for the proxy binding acknowledgement message and a new mobility option to be carried on the binding acknowledgement message for this purpose. "Generic Server Identity Check", Jeff Hodges, 10-Feb-08, This document specifies the how an entity establishing a TLS connection, or other PKI-based interaction, with a server should verify the server identity. "Secure Communication of EAP - Radius messages", Abhishek Singh, 13-Feb-08, EAP is used to establish secure communication channel in IKEv2 and in Wireless Security. EAP-TLS, EAP-TTLS, EAP-MD5, EAP-SIM uses radius protocol for communication bewteen radius server and the client. These protocols are used in both Wireless network authentication and in IKEV2 authentication to establish VPN tunnel. +----------+ +----------+ +----------+ | | EAPOL | EAP | RADIUS | | | EAP |<------>| Server |<------>| RADIUS | | Client | EAPOW | | (EAP) | Server | | | | | | | +----------+ +----------+ +----------+ This draft presents the security protocol which can be used to establish the secure communication channel between the radius server and pass through server. Pass through server is access point in the case of wireless communication and it is gateway in case of IKEV2 authnetication. "Modified Network Address Translation - Protocol Translation", Iljitsch van Beijnum, Brian Carpenter, 13-Feb-08, A smooth transition from IPv4 to IPv6 requires that either all hosts are upgraded to dual stack before the first hosts can become IPv6- only, or that there be some mechanism for IPv6-only hosts to talk to IPv4-only hosts. Expecting the former within a reasonable timeframe isn't realistic, based on current adoption of dual stack combined with the latest projections for the IPv4 depletion that point to a date early in the next decade. And the IETF has recently deprecated the main mechanism that allows the latter: NAT-PT. This document proposes a modified form of NAT-PT that addresses the reasons why the mechanism was deprecated and currently understood requirements. This should allow future deployment of the modified NAT-PT as an IPv4-to-IPv6 transition mechanism, giving operators the option of running their networks largely IPv6-only. "The DHCPv4 Relay Agent Identifier Suboption", Mark Stapp, 13-Feb-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 unique identifier configured or generated at the relay agent. The suboption allows a DHCP relay agent to include the unique identifier in the DHCP messages it sends. "FEC Grouping Issues in Session Description Protocol", Ali Begen, 14-Feb-08, The Session Description Protocol (SDP) currently supports grouping media lines. SDP also has semantics defined for grouping the associated source and Forward Error Correction (FEC)-based repair flows. However, the existing specifications have strict requirements that severely limit the use of the new features that are currently under development in the FECFRAME WG. These new features will allow applications to use FEC in a more flexible way but they require changes in the current specifications. This document provides a list of the required changes and discusses potential approaches to make these changes. "Extensions to Layer 2 Relay Agent", Bharat Joshi, Pavan Kurapati, Mukund Kamath, Stefaan De Cnodder, 14-Feb-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. "Access Node Control Protocol (ANCP) MIB module for Network Access Servers", Stefaan De Cnodder, 14-Feb-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 network access servers that are using the Access Node Control Protocol (ANCP). "Fast Route Optimization for PMIPv6 handover", Seil Jeon, Younghan Kim, 14-Feb-08, To solve the inefficient route problem of PMIPv6, a variety of mechanisms were proposed. The mechanism was also proposed to support PMIPv6 RO handover according mobile node's movements. Efficient PMIPv6 RO handover SHOULD be considered to reduce handover latency and to support communication with route optimization disabled mobile node's remote node. In this draft, we proposed a mechanism that can solve handover latency in PMIPv6 RO handover. And we introduce a few of messages to apply proposed mechanism. "Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-NAT)", Thomas Phelan, 14-Feb-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. "PIM Protocol States Diagnostics", Bharat Joshi, Archana Patel, Janardhan Kulkarni, 14-Feb-08, Multicast networks are being deployed in large numbers. It becomes very important that, proper mechanisms are in place for troubleshooting error conditions and diagnosing other failure situations. Since multicasting has little support from IP in this matter (since ICMP does not support multicasting and broadcasting) it behooves that, multicast routing protocols, embed these features in themselves. There are various debugging tools available to debug Multicast connectivity [ssmping][3] and to trace multicast routes [mtrace][4] but there is none to diagnose, troubleshoot routing protocol states. Since PIM protocol family is probably the most widely used multicast routing protocol, this draft suggests an extension to PIM protocol to diagnose and troubleshoot various PIM states in PIM routers. "More Features for TWAMP", Al Morton, Kaynam Hedayat, 14-Feb-08, The IETF IP Performance Metrics Working Group is completing its work on TWAMP - the Two-Way Active Measurement Protocol. This memo describes additional features for TWAMP, such as the ability to use different security modes in the TWAMP-Control and TWAMP-Test protocols. "Displaying Downgraded Messages for Email Address Internationalization", Kazunori Fujiwara, 14-Feb-08, This document describes how to display downgraded messages which originally contain internationalized E-mail addresses or internationalized header fields. "RTP Payload Format for H.264 Video", Ye-Kui Wang, Stephan Wenger, Miska Hannuksela, Thomas Stockhammer, Magnus Westerlund, 14-Feb-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. "Home Automation Routing Requirement in Low Power and Lossy Networks", A Brandt, 15-Feb-08, This document presents the home control and automation application specific requirements for Routing in Low power and Lossy Networks (RL2N). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include lighting control modules, heating control panels, light sensors, temperature sensors, gas/water leak detector, motion detectors, video surveillance, healthcare systems and advanced remote controls. Because such devices only cover a limited radio range, multi-hop routing is often required. Such devices are usually highly constrained in terms of resources such as battery and memory and operate in unstable environments. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home network environment. "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", David Black, David McGrew, 15-Feb-08, An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol. The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload. "Applicability Statement for the Use of Pre-Congestion Notification in a Resource-Controlled Network", Tina Tsou, Tom Taylor, 15-Feb-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, 15-Feb-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. "Spam feedback for SIP", Saverio Niccolini, Kai Fischer, Dan Wing, Martin Stiemerling, Hannes Tschofenig, 15-Feb-08, This document gives on overview of possible mechanisms for SIP UAs to feedback spam information to the system (e.g. other SIP entities like upstream SIP proxies) thus they can use this information for handling subsequent calls (e.g. blacklist the caller, input this info to reputation systems, compute spam-specific caller statistics, etc.). "NICE: Non Session Initiation Protocol (SIP) usage of Interactive Connectivity Establishment (ICE)", Jonathan Rosenberg, 15-Feb-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 been based on the offer/answer model. This document defines a SIP independent subset of ICE, called NICE, which can be used with any protocol wishing to establish a direct host-to-host relationship through NAT. Protocol specifications need only reference this document, and include the object defined here in their messages, in order to achieve NAT traversal. "What is a Session Initiation Protocol (SIP) Trunk Anyway?", Jonathan Rosenberg, 15-Feb-08, The term "Session Initiation Protocol (SIP) Trunk" has become almost commonplace amongst vendors and SIP providers. Even though the notion of a 'trunk' has a well defined meaning in circuit switched systems, it has never been defined for SIP. This document provides a formal definition for a SIP trunk, discusses its scope and applications, and establishes best practices for identification and security of SIP trunks. "Proxy Mobile IPv6 and Mobile IPv4 interworking", Meghana Sahasrabudhe, Vijay Devarapalli, 15-Feb-08, The Proxy Mobile IPv6 protocol provides mobility management for an IPv4-only mobile nodes. It provides network-based mobility management and session continuity for the IPv4 mobile node as long as the mobile node is attached to the Proxy Mobile IPv6 domain. The mobile node that attaches to the Proxy Mobile IPv6 domain, may also implement Mobile IPv4. When a Mobile IPv4-capable mobile node attaches to a Proxy Mobile IPv6 domain, there are some interactions between Proxy Mobile IPv6 and Mobile IPv4 that need to be studied. This document looks at a particular scenario where the mobile node transitions between using Proxy Mobile IPv6 and Mobile IPv4. "Linguistic Guidelines for the Use of Arabic Characters in Internet Domains", Abdulaziz Al-Zoman, Ayman El-Sherbiny, Mansour Farah, Ibaa Oueichek, 15-Feb-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. "Radius Mobility Extensions", Vamsi Gondi, Nazim Agoulmine, 15-Feb-08, Increase in the usage of different access networks, the role of Radius server is increased to provide access across different access networks and access technologies. AAA server provides access to user terminals in different security mechanisms in access networks. Due to the robust architecture of radius server, the functionalities of server can be extended to provide different services other than the authentication and access to the user terminal. In this draft we are proposing to extend the functionalities of the radius server for the mobility management of the user in the access networks. In this process the Radius server performs the mobility context management of the user when its roaming or during handover from the visiting network and the home network. In this draft we are proposing to accommodate Proxy Mobile IP (PMIP) using these extensions. In this proposed architecture we have defined new attributes and packet format when a Radius server communicates with the MPA/HA of the PMIP architecture as well as with another Radius server for context management. "Session Based Trivial Object Transfer and Exchange (TOTE)", Jonathan Rosenberg, 15-Feb-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, 15-Feb-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). "Mobility Management using AAA mobility extensions and Proxy Mobile IPv4", Vamsi Gondi, Nazim Agoulmine, Toan TRAN, 16-Feb-08, Mobility access through IPv4 and IPv6 provides seamless services for the user terminals across different access networks. To provide seamless continuity while the mobile is moving from one access networks to another is provided by different mechanisms, on the whole the proposed mechanisms provides mobility with special requirements access mechanism. The foremost popular of the mobility mechanisms is provided by Charles Perkins in mobile IPv4 IETF RFC 2002. There are some of the issues that MIP doesn't provide as a total mobility solution. The Proxy MIP is a mobility mechanism to ensure mobility management of the user terminal in different access networks. This method provides the network based mobility management without any client interactions. By this method the signaling overhead and the latency during the handover and roaming is reduced. In this proposed mechanism the mobile node doesn't need to have support for the mobility instead the access network provide the mobility for the user terminal. Even though the proxy mobile IPv4 provides the mobility management there are some of the issues that have to be solved for the network controlled mobility management. In this proposed draft we proposed new mechanism using proxy mobile IP with the mobility extensions provided by the AAA server at the time of authentication and authorizing a user terminal. Later in the draft we discuss the novel architecture and packet format for PMIP interactions with AAA of the access networks. "IPFRR in the Presence of Multiple Failures", Stewart Bryant, Mike Shand, 16-Feb-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, 16-Feb-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 and circuit ID", Pavan Kurapati, D.T.V. Ramakrishna Rao, Bharat Joshi, 16-Feb-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 new query types, query by remote ID and query by circuit ID, to address these issues. "Normalization in the unused header fields of TCP/IP", Abhishek Singh, 16-Feb-08, The unused fields in TCP/IP can be used to establish malicious communication channel[1][2][3]. This draft presents the fieldsin TCP/IP and ICMP messages and the values which must be enforced before the packets are streamed to the network so as to prevent the malicious communication channel. "ILNP Concept of Operations", Randall Atkinson, 16-Feb-08, This document is a contribution to the IRTF Routing Research Group. It is NOT a contribution to the IETF or to any IETF Working Group or to any IETF Area. This documents the Concept of Operations for an experimental extension to IPv6 which is known as the Identifier Locator network protocol. "A profile for Bogon Origin Attestations (BOAs)", Geoff Huston, Terry Manderson, George Michaelson, 17-Feb-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 describe or encompass any of the addresses listed in the BOA, and also provides a means of verifying that BGP speaker is not using an AS as a BGP speaker without appropriate authority to use that AS. The proposed application of BOAs is intended to fit within the requirements for adding security to inter-domain routing, including the ability to support incremental and piecemeal deployment of security measures, and does not require any changes to the specification of BGP. "Concerns around the Applicability of RFC 4474", Jonathan Rosenberg, 17-Feb-08, RFC 4474 defines a mechanism for secure identification of callers in the Session Initiation Protocol (SIP). This mechanism has been used as the foundation for some recent additional work, including connected party identification, anti-spam, and secure media. However, concerns have been raised about the applicability of RFC 4474 in real deployments and the actual level of security services it provides. This document describes those concerns. "Change Process for the Session Initiation Protocol (SIP)", Jon Peterson, Cullen Jennings, 15-Feb-08, This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The RAI Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. "Implications of for SIP Location Conveyance", Jon Peterson, Ted Hardie, John Morris, 17-Feb-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. "Describing CS audio streams in the Session Description Protocol (SDP)", Miguel Garcia-Martin, Simo Veikkolainen, 17-Feb-08, This memo describes use cases and requirements for controlling circuit-switched media streams using the Session Description Protocol (SDP). Additional, it proposes conventions on how to use SDP and the SDP capability negotiation framework for agreeing on alternative media streams between the endpoints. "Identity Based Authentication in the Session Initiation Protocol", Harsh Patil, Dean Willis, 17-Feb-08, Session Initiation Protocol is the Internet Engineering Task Force's standard for multimedia communications in an IP network. Authentication in SIP has been a major concern and most of the existing authentication mechanisms in SIP are dependent on public key infrastructure (PKI) or shared secrets (passwords).This document proposes new authentication schemes in SIP using identity-based signature and signcryption schemes. This approach provides security comparable to that of certificate-based authentication while preserving the operational simplicity of shared-secret techniques. "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", Quintin Zhao, Daniel King, Tomonori Takeda, Fabien Verhaeghe, 17-Feb-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. "Call Completion for Session Initiation Protocol(SIP)", Dale Worley, Martin Huelsemann, Denis Alexeitsev, 15-Feb-08, This document analyzes the interoperability problems surrounding the call-completion feature that allows a callee to put a caller's request into a queue by which the caller can be notified to call back the callee at later time. This document analyzes how different solutions inter-operate and tries to make recommendation on how to best meet this requirement "Feature Referral in the Session Initiation Protocol (SIP)", Francois Audet, Alan Johnston, Rohan Mahy, Cullen Jennings, 17-Feb-08, Feature referral allows for an application to make a high level request to a User Agent to perform an action or "feature", and let the the User Agent actually execute the feature as it sees fit. Feature referral uses the SIP REFER method with a Refer-To header field containing a URN. "MLDv2 User Authentication Problem Statement", Ya Liu, Behcet Sarikaya, Peilin Yang, 17-Feb-08, This document defines architectural considerations and problem statement for authenticating the user before entering into a multicast group using the multicast listener discover protocol version 2 (MLDv2). The issues regarding identifying multiple users, authenticating the channel, accounting, mobile multicast and security are identified. "Prefix Management for MIPv6 Home Link Operation over P2P Links", Behcet Sarikaya, Frank Xia, 17-Feb-08, In Mobile IPv6 home link operation on point-to-point links requires that one prefix can only be assigned to one mobile node by the home agent (HA) and different mobile nodes can not share this home network prefix. Managing Per-MN home network prefixes is likely to increase the processing load at the HA. Based on the idea that DHCPv6 servers can manage prefixes, we propose a new technique in which HA offloads delegation and release tasks of the prefixes to the DHCPv6 server. HA requests a prefix for an incoming mobile station to the DHCPv6 server. Based on this prefix, the mobile node can create a home address. When the mobile node leaves the network, the prefix is returned to the DHCPv6 server. "The SIP Identity Baiting Attack", Hadriel Kaplan, Dan Wing, Intellectual Property, 22-Feb-08, This document identifies a potential SPIT and Phishing attack, which subverts the RFC 4474 SIP Identity and RFC 4916 Connected Identity mechanisms in a particular way. The attack is termed "Baiting", as it uses a RFC4474-signed call as the bait for malicious use. "Problem Statement and Requirement: Protocol between Mobile Access Point and Terminal", Hui Deng, 17-Feb-08, This document discusses the problem and requirement of 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 GSM, GPRS, WCDMA, LTE, WLAN, WiMAX, and TDS-CDMA et al. Each of these wireless communication has independent connection, mobility and configuration management. This document would like converge all these function into a common ground especially in the environment of multiple connections. "Problem Statement and Requirement: Inter Mobile Access Router Protocol", Hui Deng, 17-Feb-08, This document discusses the problem and requirement of the communication between mobile access router. With the evolution of mobile communication, mobile wirless access point will not only using IP for transporation, but also has much more function to support mobile communication such as self organization/optimization network, flat network archtiecture, multiple connections and distributed network architecture et al . "SNMP Context Mapping MIB", Thomas Nadeau, Kiran Koushik, 22-Feb-08, This document defines a MIB module to manage the usage of SNMP contexts. Specically, within for an SNMP agent which implements multiple copies/instances of some other MIB module, this MIB module provides a mapping between SNMP Contexts and the individual instances of that other MIB module. "Updates to LDP for IPv6", Vishwas Manral, Rajiv Papneja, 25-Feb-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", Vishal Zinjuvadia, Rajeev Manur, Subi Krishnamurthy, Arun Viswanathan, 18-Feb-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. "Guidelines for Internationalized Email Clients", Ernie Dainow, Kazunori Fujiwara, 18-Feb-08, This document provides some guidelines for electronic mail clients that support Email Address Internationalization (EAI). A number of interoperability cases between different versions of email components are reviewed. Some User Interface recommendations are made that will minimize discrepancies between the display of composed and received email in different language environments. "Regional VPLS", Vach Kompella, Joe Regan, Ron Haberman, Shane Amante, 18-Feb-08, This draft proposes an alternative signaling approach that improves the scaling of HVPLS, which is compatible with the basic HVPLS model. It reduces the learning requirements on the PE, for certain topologies. "Mechanisms for safely abandoning loop-free convergence (AAH)", Mike Shand, Stewart Bryant, Pierre Francois, 18-Feb-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. "IPsec secured GRE tunnel demultiplexing problem statement", Yuanchen Ma, Hui Deng, Yingzhe Wu, 18-Feb-08, This document describes the IPsec secured GRE based VPN demultiplexing problem statement. When two or more IPsec SAs are used to protect GRE encapsulated VPN network between the same pair of edge router, the current GRE based VPN does not support the edge router to demultiplex data for different IPsec SA. GRE key provides one solution to demultiplex the VPNs secured by IPsec. "Why RTP Does Not Mandate a Single Security Mechanism", Colin Perkins, Magnus Westerlund, 18-Feb-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. "GRE Tunnel Request Option for Mobile IPv6", Sri Gundavelli, Kent Leung, 18-Feb-08, This document specifies a new mobility option for use in Mobile IPv6 Binding Update and Binding Acknowledgement messages. This option can be used by a mobile node or a mobile router to request the home agent to enable GRE encapsulation mode for the datagram tunneling. The GRE encapsulation mode can be negotiated for IPv6 transport and also for the IPv4 transport when using Dual-Stack Mobile IPv6 extensions. "HTTP-based IETF Namespace URIs at IANA", Martin Duerst, Tim Bray, 18-Feb-08, This document creates a registry and defines a procedure to allow IETF specifications to register XML Namespace Names with IANA which are HTTP URIs and thus potentially useful for looking up information about the namespace. "SCTP-Based Media Transport in the Session Description Protocol.", Salvatore Loreto, Gonzalo Camarillo, 18-Feb-08, Stream Control Transmission Protocol (SCTP) provides a realiable communication channel between two end-hosts in may way similar to TCP. This document describes how to express media transport over SCTP using the Session Description Protocol (SDP). It defines the SDP 'SCTP' protocol identifier. "A BGP Inter-AS Cost Attribute", Iljitsch van Beijnum, 18-Feb-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, most notably, the AS path. "Locater ID proposal evaluation", Anne-Louise Burness, Philip Eardley, 18-Feb-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, 18-Feb-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. "Session Description Protocol (SDP) Extensions and Conventions for Collaboration Applications", Miguel Garcia-Martin, Joerg Ott, 18-Feb-08, The Session Description Protocol (SDP) is typically used in conjunction with the Session Initiation Protocol (SIP) for establishing multimedia sessions on the Internet. Typically these sessions include audio, video or messaging streams. Rich collaboration applications can complete these multimedia sessions, including view sharing with remote manipulation, co-web browsing, and file transfer.This document discusses rich collaboration between two endpoints and provides conventions and extension to SDP to enable these applications. "Names of States in the life of a DNSKEY", Olafur Gudmundsson, Johan Ihren, 18-Feb-08, This document recommends a specific terminology to use when expressing the state that a DNSKEY is in at particular time. This does not affect how the protocol operates in any way. "OpenLISP Implementation Report", Luigi Iannone, Olivier Bonaventure, 18-Feb-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. UC Louvain is working on an implementation of this protocol on a FreeBSD platform. The present draft describes the overall architecture of this implementation and its main data structures. "HIP Certificates", Tobias Heer, Samu Varjonen, 18-Feb-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 certificates. It is used for carrying these certificates in HIP control messages. Additionally, this document specifies the representations of Host Identity Tags in SPKI certificates. "Secondary Binding Cache entries for Proxy MIPv6", Oliver Blume, Rolf Sigle, 18-Feb-08, The IETF is specifying Proxy Mobile IPv6 for network-based localized mobility management, which takes basic operation for registration, tunnel management and de-registration into account in a first protocol release. This document proposes an extension to Proxy Mobile IPv6 to suit MNs, which have multiple network interfaces implemented and can be connected over more than one network interface at the same time. This extension introduces a secondary binding at the local Mobility Anchor (LMA) that is valid for receiving uplink packets but is not used for tunneling downlink packets towards the MN. This allows for preparation of the new binding while avoiding that the LMA will prematurely forward data packets to the mobile node's new interface before the address configuration of this interface has completed. Furthermore, secondary bindings can be used to avoid loss of delayed packets arriving at the LMA after the Binding Cache has been updated by a Proxy Binding Update from a new MAG. With the proposed extension, packet buffering at the new MAG is not necessary and packet losses during an inter-technology handover can be mitigated. "RUCUS Problem Statement", David Schwartz, 18-Feb-08, SIP is being used more an more today for everyday communication purposes. With this widespread adoption comes the inevitability of abuse. This document describes the problems that fit into the category of "unwanted Communication". "Indirect Presence Publication with the Session Initiation Protocol(SIP)", Miguel Garcia-Martin, Hannes Tschofenig, Henning Schulzrinne, 18-Feb-08, SIP is extended by the SIP-events framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is 'presence' and this presence information is carried in Presence Information Data Format (PIDF) documents. The SIP PUBLISH method specified in RFC 3903 carrying a PIDF document is typically used when presentities publish their own presence since these presentities are typically the source of the information. However, there are cases when the presentity is not the direct source of the presence information. One such example is location information where the end host may obtain a reference to location information as opposed to as a value. The endpoint is typically not interested in knowing its own location information, but other users or entities might be. So, if the endpoint gets its own location information with a reference and wants to publish it embedded in its presence information, it first needs to de-reference it for getting a value, and then it can embed that value in its presence information. While this is certainly a correct sequence, it adds a round-trip to the presence publication, in addition to a demand processing power and network bandwidth consumption. There is a need for a mechanism that the presentity can use to publish indirect references, such as indirect location references. This document discusses a few variants that may be used to provide this functionality. "The case for an informed path selection service", Damien Saucez, Benoit Donnet, 18-Feb-08, With today's peer-to-peer applications, more and more content is available from multiple sources. In tomorrow's Internet hosts will have multiple paths to reach one destination host with the deployment of dual-stack IPv4/IPv6 hosts, but also with new techniques such as shim6 or other locator/identifier mechanisms being discussed within the IRTF RRG. All these hosts will need to rank paths in order to select the best paths to reach a given destination/content. In this draft, we propose an informed path selection service that would be queried by hosts and would rank paths based on policies and performance metrics defined by the network operator to meet his traffic engineering objectives. A companion document describes a protocol that implements this service. "Spam score for SIP: a proposal for semantics", Jan Seedorf, Saverio Niccolini, Henning Schulzrinne, 18-Feb-08, This document reports a proposal for semantics of SIP spam scoring in order to achieve a flexible signalling standardization allowing an incremental adoption of the scoring mechanism. This approach can give early experimental implementers the possibility to start using spam scoring extensions in an explorative fashion without running into interoperability problems. "E.164 Ownership using Public Keys stored in ENUM", Klaus Darilion, Hannes Tschofenig, 18-Feb-08, To determine which domain is allowed to claim ownership of a certain telephone number is difficult. This may cause problems when to authenticate endpoints that use telephone number URIs and domain names in their From address. This document investigates a proposal that stores a public key below the corresponding ENUM tree in the DNS. The verifier can determine ownership by performing an ENUM lookup to retrieve the public key from the DNS and to use it for verifying the signature created as part of the SIP Identity mechanism. This document is a contribution to the ongoing discussion on RFC 4474 when used in combination with E.164 numbers. "New Information Elements from the IPFIX Information Model", Paul Aitken, Benoit Claise, 17-Mar-08, This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order Aitken, Claise Standard Track [page 1] New Information Elements for the IPFIX Information Model March 2008 to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a number of transport protocols from an IPFIX exporting process to an IPFIX collecting process. "IDIPS : ISP-Driven Informed Path Selection", Damien Saucez, Benoit Donnet, Olivier Bonaventure, 18-Feb-08, This draft describes a simple network-based protocol to facilitate Path Selection and to improve traffic engineering capabilities in multihomed corporate networks. With this 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 policies and performance requirements of both the host and network provider. "Using Imprecise Location for Emergency Context Resolution", Richard Barnes, Matt Lepinski, 18-Feb-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. "Specifying a Circular Uncertainty Area Using DHCP", Hannes Tschofenig, James Winterbottom, 18-Feb-08, This document specifies how a circular area representing the location of device can be returned using DHCP. The document also shows how the data returned from DHCP can be encoded into GML for using in a PIDF-LO in an unambiguous or contentious manner. This document is a contribution to the ongoing discussion on RFC 3825; it represents one possible solution to address the discussed issues. "Mobile IPv6 Residual Threats", Wassim Haddad, George Tsirtsis, Benjamin Lim, Suresh Krishnan, 25-Feb-08, This memo aims to highlight specific residual threats in the Mobile IPv6 design. These threats are inherited in the design of new mechanisms built on top of the mobility protocol, and are raising concerns regarding the amplitude of their potential impacts. "DHCPv6 Relay Agents and NEMO", Francis Dupont, Wassim Haddad, 18-Feb-08, The IPv6 network mobility (NEMO) configuration relies on a prefix delegation service to fulfill its task. Such service has already been described in two different proposals, one is based on DHCPv6 and the other extends NEMO signaling. However, both failed to gather consensus. This memo describes how DHCPv6 Relay Agents can be used in order to provide the missing flexibility and pave the way for a solution. "Kalua - A Data Modeling Language for NETCONF", Bernd Linowski, Martin Storch, Mikko Lahdensivu, Mehmet Ersue, 11-Mar-08, This document specifies a Data Modeling Language (Kalua DML), which is designed to be used as a specification language for the payload of the IETF NETCONF protocol [RFC4741] as well as to specify other management related data models. The Kalua DML aims to fit the requirements specified in draft-linowski-netconf-dml-requirements [Linowski] and supports most of the requirements in RCDML [RCDML]. Comments can be sent to ngo@ietf.org. "Policy Profile and AAA Interfaces Requirements for PMIPv6", Jouni Korhonen, Ahmad Muhanna, 18-Feb-08, This specification defines the Policy Profile and AAA interfaces requirements for the Proxy Mobile IPv6. The Policy Profile information needed by the Proxy Mobile IPv6 may be statically provisioned in the mobile access gateway and in the local mobility anchor. Alternatively, the Policy Profile information or a subset of its parameters can be dynamically downloaded to the mobile access gateway from the AAA server during the mobile node access authentication and authorization when the mobile node roams into a Proxy Mobile IPv6 domain. The local mobility anchor may download the user policy profile parameters during the Proxy Mobile IPv6 registration process. This document describes the requirements for the Proxy Mobile IPv6 Policy Profile and the corresponding AAA interfaces. "Softwires Mesh Multicast Problem Statement", Chris Metz, Yong Cui, Mingwei Xu, 18-Feb-08, This document defines a problem statemet for Softwires Mesh Multicast. "Verifying Correctness of Alternate Care-of Address Option", Jari Arkko, 25-Feb-08, This document revises the RFC 3775 rules on how Alternate Care-of Address option is processed. Alternate Care-of Address option is used to carry the current care-of address inside a Mobility Header message. This is used in addition to the source address in the packet in order to ensure that the care-of address is protected by IPsec ESP, the security mechanism that protects Mobility Header messages. Unfortunately, RFC 3775 did not require verification that the source address and care-of address are the same. This document adds that requirement. "YANG's Compliance with Respect to Various Requirements Documents", Martin Bjorklund, 18-Feb-08, This draft addresses requirements for a NETCONF data modeling language and how the YANG Modeling Language proposes to fulfill these requirements or specifically chooses not to. Requirements have been gathered from multiple documents and each document's requirements are handled in a separate section in this draft. This draft also explains some of the design choices behind YANG. "Requirements for explicit private network indication", Hans Erik van Elburg, Keith Drage, 22-Feb-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. "Handover method using EAP", Vamsi Gondi, Nazim Agoulmine, 18-Feb-08, The increase in the use of different access networks which involves different mechanisms for authentication and access authorizations, demands the new mechanisms to roam at any time anywhere with low latency. To overcome this process we need new mechanisms where a user terminal roams in different access networks with low latency and efficiently. There is a need for unified signaling mechanisms for choosing and accessing networks. In this draft we have discussed some of the processes involved in network selection, mobility management, security management in detailed to perform handover. The Handover information is passed to home server using the new handover method using EAP proposed vice versa in this draft. Even though there are different mechanisms provide this support such as IAPP context transfer mechanisms for seamless mobility some of the instances like supporting different access networks, roaming in access networks etc is not considered. The proposed mechanism is interoperable with the existing procedures involving security authentication and mobility during roaming. "Vendor Specific Message for ANCP.", Peter Arberg, 18-Feb-08, This document is aimed at presenting Access Node Control Protocol (ANCP) with a vendor specific protocol extension. "Roaming Extensions for radius server", Vamsi Gondi, Nazim Agoulmine, 18-Feb-08, The functionalities of radius server can be extended to provide new types of services for the users in Wireless and cellular network. Traditionally Radius servers are limited to authentication, access and accounting, there are few researchers proposing new extensions to provide new functionalities for radius server in wireless and cellular networks. In this draft we are proposing to extend the functionalities of Radius to extend it to roaming and handover support for the mobile terminals. Using this mechanism the mobile terminal initially gets access to the network and then when there is a possibility of handover and roaming with the other access networks, mobile terminal communicates with the home radius server and creates the pre authentication information. In this process different mechanisms essential for roaming and handover are addressed such as Network Selection, Handover Initiation, Security Context Management, and Mobility Management. Using this mechanism the latency for handover and roaming can be reduced with higher level control mobility of the terminal during handover and roaming. "Softwires Network Address Translation (SNAT)", Ralph Droms, Brian Haberman, 18-Feb-08, Service providers (ISPs) are interested in reducing the use of IPv4 in their internal networks because of the anticipated exhaustion of the IPv4 address space. Softwires Network Address Translation (SNAT) combines IPv4 NAT and IPv4-in-IPv6 softwires to carry IPv4 traffic through the ISP network that uses only IPv6 service. Multiple subscribers are multiplexed through a single external global IPv4 address, reducing the total number of IPv4 addresses in use by the ISP to support Internet traffic to those subscribers. "SIP Usage Scenarios Similar to SPIT", Dan York, 18-Feb-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 Policy Enforcement Interface: ITU-T Rw", Dong Sun, 18-Feb-08, This document describes the need for a new pair of IANA Diameter Command Codes and a new vendor-specific Application ID 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 controlling the policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T). "IANA Allocation Guidelines for TCP and UDP Port Numbers", Michelle Cotton, Lars Eggert, Allison Mankin, Magnus Westerlund, 18-Feb-08, This document defines the IANA guidelines for registering new port number values for use with the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It provides clear processes for the TCP and UDP port number registries, important for their long-term management. It updates RFC2780 by replacing Sections 8 and 9.1 of that RFC. "Why URIs Are Changed Crossing Domains", Hadriel Kaplan, 18-Feb-08, This document discusses the reasons SIP Service Providers change To and From URI's, to provide a basis for discussion of whether such From-URI hiding tactics as [E2E-SEC-MEDIA] have a chance of success. "IP Multicast Fast Reroute Framework", Dimitri Papadimitriou, Pierre Francois, 18-Feb-08, The goal of this document is to investigate the solution space for improving the recovery time of multicast trees built by the variants of the PIM routing protocol in the case of various topological failures (including links and nodes). "The Uniform Resource Identifier (URI) DNS Resource Record", Patrik Faltstrom, Olaf Kolkman, 18-Feb-08, This document defines a new DNS resource record, called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs. "Optimizing Notifications for Presence Network Agents", Brian Rosen, Salvatore Loreto, Krisztian Kiss, 18-Feb-08, In large presence systems deployed in multiservice networks, presence information is often known by the network in addition to, or instead of the presentity's devices (endpoints). Examples of such information include location and availability for various kinds of session establishment. Even if devices know the information, the network often has more bandwidth and better scale to keep the presence server up to date. A Presence Network Agent (PNA) can publish presence information to a Presence Server(PS). When done large scale, the basic publish operation can be inefficient. When the network has millions of subscribers, only some of which have watchers, blind Publish operations are unecessary. WINFO can be used to determine watchers, but the efficiency of maintaining WINFO per subscriber, and the size of the messages involved, make that solution unattractive. The PNA would prefer to have the Presence Server simply tell it when there was at least one watcher. This document describes an XML document stored on the PS by which the PNA maintains a list of subscribers it can provide presence for as a SIP event package that tells the PNA when the number of watchers for a presentity on the list (or a specific presence element for a presentity) goes from 0 to at least 1 or from 1 to 0. "Using HTTP for delivery in Delay/Disruption-Tolerant Networks", Lloyd Wood, Peter Holliday, 25-Feb-08, This document describes how to use the Hypertext Transfer Protocol, HTTP, for communication across delay- and disruption-tolerant networks. HTTP is well-known and straightforward to implement in these networks. "An EAP Method for Key Distribution Exchange for Handover Re- authentication", Yoshihiro Ohba, Rafael Lopez, 22-Feb-08, This document describes an EAP method used for carrying KDE (Key Distribution Exchange) protocol for handover re-authentication. This method carries HOKEY KDE messages. This EAP method is designed to work with stand-alone authenticators. "Operations and Maintenance Next Generation Requirements", Shane Amante, Alia Atlas, Andrew Lange, Danny McPherson, 19-Feb-08, Current IP and MPLS OAM techniques need to be extended to permit operators to effectively diagnose load-balancing issues. Specifically, new ad-hoc OAM techniques are needed to diganose various link-bundling techniques, such as IP/MPLS Equal Cost Multi- Path (ECMP) and Link Aggregation Groups (LAG). In addition, these OAM tools should also be extended to permit performance monitoring over longer time durations. This document defines requirements for the next generation of OAM solutions. "Outline for Requirements for an EAP Tunnel Based Method", Joseph Salowey, 18-Feb-08, This memo provides an outline for the requirements for a Tunnel Extensible Authentication Protocol (EAP) Method. This method will use Transport Layer Security (TLS) to establish a tunnel. The tunnel will support password authentication, EAP authentication and the transport of additional data for other purposes. "Internationalized Domain Names: Alternatives to IDNA", John Klensin, 18-Feb-08, The Internet protocol for internationalized domain names (IDNs) is documented in RFC 3490 and associated documents and commonly known as IDNA. While that protocol was being developed (and more recently), there were a number of alternate proposals and suggestions for different ways to do IDNs. IDNA was favored over those alternatives, but variations on them seem to keep reappearing with the suggestion that they are novel ideas. This memo describes some of those suggested alternatives and summarizes the reasons why they were not favored over IDNA. "E.164 Ownership Problem Statement", David Schwartz, Hadriel Kaplan, Klaus Darilion, Hannes Tschofenig, 25-Feb-08, When a call travels end-to-end relayed from the PSTN to SIP then problems occur with E.164 number ownership. Additionally, there are security challenges when the PSTN-VoIP gateway has to authenticate and authorize the calling party. Without addressing these two aspects the overall security story is weak or non-existent. This document aims to investigate these two aspect; it does, however, not investigate current E.164 number handling with RFC 4474 ("SIP Identity"). Such an analysis is provided by other documents already. "Simultaneous Mobility Problem Statement", Daniel Wong, Ashutosh Dutta, Henning Schulzrinne, 18-Feb-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. "Signaling Protocol to convey FEC Framework Configuration Information", Rajiv Asati, 18-Feb-08, FEC Framework document [FECARCH] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes one signaling protocol to determine and 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. "P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP)", Dan York, Tolga Asveren, 25-Feb-08, This document describes 'P-Charge-Info', a private Session Initiation Protocol (SIP) header (P-header) used by a number of equipment vendors and carriers to convey simple billing information. "ProxyMIP Extension for Inter-MAG Route Optimization", Ashutosh Dutta, Subir Das, Hidetoshi Yokota, Tsunehiko Chiba, Henning Schulzrinne, 18-Feb-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. "1-D and 2-D Parity FEC Scheme for FEC Framework", Ali Begen, Rajiv Asati, 18-Feb-08, This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the one-dimensional (1-D) and two-dimensional (2-D) parity codes and its application to reliable delivery of media streams in the context of FEC Framework. The 1-D and 2-D parity codes are systematic codes, 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 1-D and 2-D parity codes offer a good protection against random and bursty packet losses at a cost of decent complexity. This document also specifies an RTP payload format for the FEC that is generated by the 1-D and 2-D parity codes from a source media encapsulated in RTP. The FEC defined in this document is not backward compatible with RFC 5109. "Provisioning Protocol Requirements for ENUM-SIP Addressing Servers", Tom Creighton, Jean-Francois Mule, 18-Feb-08, This document presents use cases and protocol requirements for provisioning ENUM-SIP addressing servers. The provisioned data is used by an addressing server to return part of the session establishment data to SIP entities so that they can route SIP sessions to the target destinations. "A Provisioning Protocol for ENUM-SIP Addressing Servers", Kenneth Cartwright, Stephen Dimig, Mark Teodoro, Jean-Francois Mule, 25-Feb-08, This document defines a provisioning protocol for ENUM-SIP addressing servers. This protocol has been recently published as part of CableLabs(r) PacketCable(tm) specifications. It 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. "Extensions to RTSP based on the CableLabs Edge Resource Management Interface Specification (ERMI)", Charles Bergren, Jean-Francois Mule, 18-Feb-08, This document provides a description of the RTSP extensions used in the CableLabs Edge Resource Manager Interface specification. It is provided as an informational note based on a recent liaison statement received by CableLabs from the IETF MMUSIC working group. "Guidelines for Extending the RTP Control Protocol (RTCP)", Joerg Ott, Colin Perkins, 18-Feb-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. "MIKEY General Extension Payload for OMA BCAST LTKM Reporting and Parental Control", Lakshminath Dondeti, David Castleford, Frank Hartung, 18-Feb-08, This document extends the General Extension Payload for OMA BCAST usage defined in RFC 4909. 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. "Defining Netconf Data Models using Document Schema Definition Languages (DSDL)", Rohan Mahy, Sharon Chisholm, Ladislav Lhotka, 10-Mar-08, This document describes a concrete proposal for creating 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. "Proxy MIPv6 Support of Transient Registration", Ahmad Muhanna, Suresh Krishnan, Kent Leung, Basavaraj Patil, 25-Feb-08, In order for the local mobility anchor to receive and forward uplink traffic for a mobile node, Proxy Mobile IPv6 base protocol mandates the LMA to have an active BCE with a registered proxy CoA that is the other end of the tunnel between the LMA and MAG. In some systems and during active inter-MAG handoff with traffic that is sensitive to delay and packet loss, the LMA is required to forward uplink traffic for the mobile node from the target MAG without completely switching the tunnel from the source MAG. This document specifies a mechanism which allows the target MAG to perform transient registration for a new proxy CoA and the LMA to create a transient BCE for the same mobile node for a specified period of time while maintaining the original mobile node's BCE which reference the old pCoA at the source MAG. "Hierarchical Host Identity Tag Architecture", Sheng Jiang, 18-Feb-08, This document analyzes the problems and limitation of the current flat-structured Host Identity Tag (HIT, [RFC4423]) 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 HIP 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, 25-Feb-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, 25-Feb-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. "Edge-Assisted Marked Flow Termination", Michael Menth, Frank Lehrieder, Philip Eardley, Anna Charny, Jozef Babiarz, 18-Feb-08, This document presents edge-assisted marked flow termination (EMFT) for PCN. It assumes packet-size independent excess marking, i.e. packets exceeding the supportable rate (SR) of a link are marked as "excess-traffic" (ET). EMFT terminates only flows with at least one ET-marked packet. The problem is to avoid that all flows with ET- marked packets are terminated. This draft proposes two solutions. Flow-based EMFT (F-EMFT) considers single flows separately and terminates them when sufficiently many packets of them have been received by the PCN egress node with an ET-mark. Aggregate-based EMFT (A-EMFT) considers ingress-egress-aggregates and terminates flows thereof sufficiently many ET-marked packets have been received for that aggregate. "Diameter Application for Authentication and Authorization in Web Applications", Niklas Neumann, Xiaoming Fu, 18-Feb-08, This document specifies the Diameter Application for Authentication and Authorization in Web Applications (Diameter WebAuth). This Diameter application is intended to be used by Diameter clients to perform authentication and authorization operations with a Diameter server in web-based environments. It provides facilities to allow web sites to authenticate their web user clients using a number of (HTTP) authentication schemes. In addition, it supports user authorization using dedicated service identifiers. Diameter WebAuth may also be used by non web-based Diameter clients and servers that require a lightweight authentication and authorization Diameter application. "PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC", Paul Sangster, 18-Feb-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. "PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC", Ravi Sahita, Stephen Hanna, Ryan Hurst, 18-Feb-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 Security: A Posture Attribute (PA) Security Protocol", Paul Sangster, 18-Feb-08, This document specifies PA-TNC security, a Posture Attribute Security Protocol identical to the Trusted Computing Group's IF-M Security Binding to CMS 1.0 protocol. PA Security offers origin authentication, integrity and optional confidentiality protection for one or more PA attributes. The document then evaluates PA-TNC Security against the requirements defined in the NEA Requirements specification [5]. "Configuring BFD with DHCP and Other Musings", Vitali Vinokour, David Ward, 18-Feb-08, This document defines a method for configuring Bidirectional Forwarding Detection (BFD) by an IP Edge device using DHCPv4 or DHCPv6. It provides motivation for the new functionality, defines new DHCP options to assist with the task and outlines the rules for configuring BFD on an IP endpoint for different network topologies. The document also discusses endpoint behavior upon BFD failure. Comments on this draft should be directed to rtg-bfd@ietf.org. "IEEE1588V2 telecom profile framework", Kuiwen Ji, Xiaodong Duan, 22-Feb-08, This Internet draft proposes the framework of IEEE1588V2 telecom profile. "The requirement of extending RFC4666 for the M3UA deployment", Zhao Yuyi, 18-Feb-08, RFC 4666 defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. M3UA is designed for SEP-(TDM)-SG-(IP)-IPSEP and IPSEP-(IP)-IPSEP applications, so the network level management function isn't required. SSNM(SS7 Signalling Network Management) messages defined in M3UA are only used for interworking with SS7. RFC 4666 doesn't define IPSEP- IPSTP-IPSEP application of M3UA. The signalling network management function for this application needs to be extended. Some parts of the specification are unclear,which may lead to misinterpretations and may weaken interoperability. This document provides extensions and clarifications to RFC 4666. "Key Distribution Center Address Option for DHCPv6", Shoichi Sakane, Yukiyo Akisada, Ken'ichi Kamada, 18-Feb-08, This document defines a new DHCPv6 option to convey a realm of Kerberos and IPv6 addresses of a KDC of that realm. "Diameter extensions for MoS discovery", Jouni Korhonen, Telemaco Melia, 18-Feb-08, IEEE 802.21 standard defines three distinct service types to facilitate link layer handovers across heterogeneous technologies. This document focuses on the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface defining a number of Diameters AVPs containing domain names or IP addresses. Such information is related to IEEE 802.21 services assisting a mobile node in handover preparation (network discovery) and handover decision (network selection). "Definition of Managed Objects for the DYMO Manet Routing Protocol", Robert Cole, Ian Chakeres, 18-Feb-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 MANET Routing process on a router. The DYMO MIB also reports state information, i.e., Routing Information Base entries, performance metrics, i.e., counter of the number Routing Messages, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting routing problems. "Requirements for the graceful shutdown of BGP sessions", Bruno Decraene, Pierre Francois, cristel pelsser, Zubair Ahmad, Antonio Jose Elizond Armengol, 18-Feb-08, The BGP protocol is heavily used in Service Provider networks both for Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an AS Border Router or BGP session breakdown on customers' or peers' traffic. However simply taking down a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no more satisfactory for new applications (e.g. voice over IP, on line gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP Requirements for the graceful shutdown of BGP sessions session(s) in order to limit the amount of traffic loss during a planned shutdown. This document expresses requirements for such a solution. "Ivip Mapping Database Fast Push", Robin Whittle, 18-Feb-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. "Media Independent Handover Network Signalling Layer Protocol (MIH NSLP)", Susana Sargento, Giada Landi, Xiaoming Fu, 18-Feb-08, This memo defines the Media Independent Handover Network Signalling Layer Protocol (MIH NSLP) for the transport of messages from the IEEE 802.21 standard using the Next Steps in Signalling (NSIS) framework. The MIH NSLP is responsible for the transport of MIH messages to remote entities reporting on link layer information, in order to support seamless mobility in heterogeneous environments. A usage example of the MIH NSLP is also provided. "Path Computation Element communication Protocol (PCEP) Extensions for Point to Multipoint Label Switched Paths (LSPs)", Mohamad Chaitou, Jean-Louis Le Roux, Zafar Ali, 18-Feb-08, The Path Computation Element communication Protocol (PCEP) enables computing point-to-point Traffic Engineered (TE) paths in Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. This document describes extensions to PCEP in order to support the computation of point-to-multipoint (P2MP) Traffic Engineered (TE) paths. "RTP Payload Format for GSM-HR Speech Codecs", Xiaodong Duan, Shuaiyu Wang, Rocky Wang, Ying Zhang, 18-Feb-08, This document registers a media type for the Real-time Transport protocol (RTP) payload format, which is used for the Group Special Mobile half-rate speech transcoding. "Automatic Method for Minimization of Extraneous Pseudonodes in IS-IS", Radia Perlman, Abhay Roy, Matthew Thomas, 18-Feb-08, An automatic method is recommended for a link state protocol to automatically decide whether an Ethernet link should be represented by a pseudonode or not. Included is encoding recommendations for IS- IS for implementing this feature. "RBridges: Use of IS-IS", Donald Eastlake 3rd, Radia Perlman, Dinesh Dutt, 18-Feb-08, RBridges use 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. 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 is an early specification of the details of TRILL use of IS-IS for purposes of discussion "draft-eastlake-trill-rbridge-options-00.txt", Donald Eastlake 3rd, 18-Feb-08, The TRILL base protocol specification, draft-ietf-trill-rbridge- protocol-07.txt, specifies minimal hooks for options. This early draft more fully describes a format and an initial set of options for purposes of discussion. "Automatic Method for Minimization of Extraneous Pseudonodes in OSPF", Radia Perlman, Abhay Roy, Matthew Thomas, 18-Feb-08, "Automatic Method for Minimization of Extraneous Pseudonodes", Radia Perlman, Abhay Roy, Matthew Thomas, 18-Feb-08, An automatic method is recommended for a link state protocol to automatically decide whether an Ethernet link should be represented by a pseudonode or not. "One time Password in Internet Key Exchange Protocol version 2", Abhishek Singh, Sunil Kumar, 13-Mar-08, IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). This document presents the changes in Internet Key Exchange Version 2 for one time password. "Hierarchical Routing Architecture (HRA)", Dayong Guo, Xiaohu Xu, 18-Feb-08, This document describes a new routing and addressing architecture, which is based on identifier/locator split idea. This architecture introduces a hierarchical routing mechanism to support routing across multiple independent address spaces, besides, it also adopts a hierarchical host identifier to ease the management of a global identifier/locator mapping system. "EAP Method Support for Transporting AAA Payloads", Charles Clancy, 18-Feb-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, 18-Feb-08, This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods. "Multicast Mobility Problem Statement", Behcet Sarikaya, Suresh Krishnan, 18-Feb-08, This document discusses problems that are caused due to the mobility of multicast receivers. It also divides the problems based on the protocols that they need to be fixed in. "Cryptographic Algorithm Implementation Requirements for Routing Protocols", Manav Bhatia, Vishwas Manral, 23-Feb-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 SHA family of hash algorithms for authenticating routing protocol packets for RIP, 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. "Conversation Hashing for Pseudowires", Vach Kompella, Joe Regan, Shane Amante, 18-Feb-08, V. Kompella Expires August 2008 [page 1] Internet-Draft Hashing on Pseudowires February 2008 This draft proposes a method to introduce granularity on the hashing of traffic running over pseudowires. Most forwarding engines are able to hash based on label stacks, so the approach here is to introduce additional labels that do not affect the handling of packets, but which identify a conversation, and can be hashed with granularity. "SAM Overlay Protocol", John Buford, 13-Mar-08, The previously proposed Hybrid Overlay Multicast Framework uses a structured peer-to-peer overlay to connect peers in different types of multicast regions of the Internet. We use AMT (Automatic IP Multicast Without Explicit Tunnels) to connect peers in ALM (Application Layer Multicast) regions with peers in native multicast regions. Here we define the overlay messaging needed to support the multicast tree operations. One goal of this approach is to ensure that the SAM framework is compatible with the P2P-SIP overlay, which is still being defined. Another goal is to be overlay agnostic so that different overlay algorithms can interoperate in a single SAM (Scalable Adaptive Multicast) session. "A proposal for modification of BGP 4-octet AS number usage", Samita Chakrabarti, 1-Mar-08, "Security Parameter Index multiplexed Network Address Translation (SPINAT)", Jan Melen, Jukka Ylitalo, Patrik Salmela, 10-Mar-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. "DNSSEC protected routing announcements for BGP", Lutz Donnerhacke, 11-Mar-08, This document describes an infrastructure for real time verification of routes reveived via BGP4. Some DNS query types are introduced to check the origin of a prefix and validity of the AS path. The crypto part can be offloaded from the routing engine by sending a DNS query and checking the AD bit in the DNS response. The proposal depends on the DNS scalability and caching mechanisms as well as PKI introduced by DNSSEC. "Subnetwork Encapsulation and Adaptation Layer", Fred Templin, 13-Mar-08, SEAL is related to problem spaces currently under investigation in the IRTF Routing Research Group, as well as the IETF INTAREA general area and IETF AUTOCONF and MANET working groups. SEAL addresses packet size issues for IP-in-IP tunnels, with improved duplicate packet detection as an additional benefit. This document is currently under construction as an individual submission, to be followed by determination of an appropriate working group (or remain as individual sub). "Requirements for a next generation Internet Time Protocol", Kurt Lindqvist, Peter Lothberg, 10-Mar-08, Providing timing services over an IP network, known as wall-clock, has traditionally been done with the Network Time Protocol, NTP. The current version of NTP, version 4, has been in existence for a long time, but only recently been adopted as an IETF Standard. In the mean time however, the requirements for higher precision of wall- clock services over IP networks has grown. This document outlines some of the requirements of wall-clock services that is not provided by NTPv4, and is intended to serve as a gap analysis. "Urban WSNs Routing Requirements in Low Power and Lossy Networks", Mischa Dohler, Thomas Watteyne, Christian Jacquenet, Giyyarpuram Madhusudan, Gabriel Chegaray, 8-Apr-08, The application specific routing requirements for Urban Low Power and Lossy Networks (U-L2Ns) 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 citizens' 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 - requires the use of suitable multi-hop 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 outdoors urban application scenario. As such, for a wireless roll solution to be competitive with other incumbent and emerging solutions, the protocol ought to be energy-efficient, scalable and autonomous. This documents aims to specify a set of requirements reflecting these and further U-L2Ns tailored characteristics. "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", Jonathan Hui, 10-Mar-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. "MPLS EXP-bits definition", Loa Andersson, 10-Mar-08, - Table of Contents "NETCONF Configuration Data Modeling using OWL", Leif Johansson, 11-Mar-08, This document outlines an approach for a NETCONF data modeling language based on the W3C Web Ontology Language (OWL). "Notes on TCP Authentication Architectures", Eric Rescorla, 11-Mar-08, This document provides an architectural survey of a variety of approaches to key management for TCP-level authentication. "Relay Based DHCPv6 Prefix Delegation for NEMO", Behcet Sarikaya, Frank Xia, 10-Mar-08, This document defines DHCP Relay Agent based prefix delegation support for a mobile network. Mobile Router uses DHCPv6 prefix delegation to dynamically request its Mobile Network Prefixes from DHCP Server. DHCP Relay Agent located in MR enables MR to run the prefix delegation application with the same DHCP Server even after MR moves to a different local network. "Prefix Delegation Support for Mobile Networks", Behcet Sarikaya, Frank Xia, 10-Mar-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. Home agents get the prefixes delegated using DHCP Prefix Delegation and reply to the Mobile Router with Binding Acknowledgement. "High-level Changes From IDNA2003 To IDNA200x", Paul Hoffman, 13-Mar-08, This document is a summary of what changes are embodied in the initial set of documents that are for IDNA200x. "Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)", David Nelson, 12-Mar-08, This memo describes the requirements for a Crypto-Agility solution for Remote Authentication Dial-In User Service (RADIUS). "SAVI Threat Scope", Danny McPherson, Fred Baker, 13-Mar-08, This memo discusses threats enabled by IP source address spoofing and discusses a number of techniques aimed at mitigating those threats. "Using HTTP for delivery in Delay/Disruption-Tolerant Networks", Lloyd Wood, Peter Holliday, 13-Mar-08, This document describes how to use the Hypertext Transfer Protocol, HTTP, for communication across delay- and disruption-tolerant networks. HTTP is well-known and straightforward to implement in these networks. "IKEv2 extensions for combating SPIT on mobile hosts", Pars Mutaf, 19-Mar-08, This document describes IKEv2 extensions for combating SPIT on mobile hosts. "Determining When to Discard or Retry a SIP Request During Overload", Timothy Moran, 14-Mar-08, SIP servers can become overload and unable 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 proposes an architecture for determining when a client should throttle the sending of SIP requests vs. retrying them. "Graceful BGP session shutdown", Pierre Francois, Bruno Decraene, cristel pelsser, 15-Mar-08, This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers, involving the shutdown of BGP peering sessions. "A Quick Crash Recovery Method for IKE", Yoav Nir, 16-Mar-08, This document describes an extension to the IKEv2 protocol that allows for faster crash recovery using a saved token method. When an IPsec tunnel between two IKEv2 implementations is disconnected due to a restart of one peer, it can take as much as several minutes to recover. In this text we propose an extension to the protocol, that allows for recovery within a few seconds of the reboot. "Sender Policy Framework: Email Address Internationalization", Frank Ellermann, 17-Mar-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 other purposes. This memo discusses some consequences for SPF (Sender Policy Framework). "LISP EID Block", Darrel Lewis, Dave Meyer, Vince Fuller, 17-Mar-08, This is a direction to IANA to allocate a /16 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP) and LISP Alternative Topology (LISP-ALT) mapping system. "LoWPAN Backbone Router", Pascal Thubert, 18-Mar-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, 18-Mar-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. "Global HA to HA protocol", Pascal Thubert, Ryuji Wakikawa, Vijay Devarapalli, 18-Mar-08, This HAHA protocol extends MIPv6 [RFC3775] and NEMO [RFC3963] to remove their link layer dependencies on the Home Link and distribute the HAs at IP layer. Global HAHA considers the distribution at the scale of the Internet, and introduces the MIP proxy for Local Mobility Management and Route Optimization in the Infrastructure. "Definition of Managed Objects for the DYMO Manet Routing Protocol", Ian Chakeres, Robert Cole, 18-Mar-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. "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity", Paul Vixie, David Dagon, 18-Mar-08, The small (16-bit) size of the DNS transaction ID has made it a frequent target for forgery, with the unhappy result of many cache pollution vulnerabilities demonstrated throughout Internet history. Even with perfectly and unpredictably random transaction ID's, random and birthday attacks are still theoretically feasible. This document describes a method by which an initiator can improve transaction identity using the 0x20 bit in DNS labels. "Location-to-Service Translation Protocol (LoST) Extensions", Andrea Forte, Henning Schulzrinne, 19-Mar-08, An important class of location-based services answer the question "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots) or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries "N nearest" and "within distance X". "Requirements for Management of Name Servers for the DNS", Wesley Hardaker, 4-Apr-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 has not been a interoperable way to control, configure and examine the internal performance of a given DNS server. 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. "Robust Header Compression over Unidirectional Lightweight Encapsulation (ULE) and MPEG2 Transport Stream (TS) frames", Tat-Chee Wan, Way-Chuang Ang, Chee-Hong Teh, 19-Mar-08, This paper introduces approach to carry ROHC packets over ULE and MPEG2-TS frames. For completeness, ROHC Channel Parameters Negotiation Protocol (RCPNP) is also presented. "Streamlined FTP Command Extensions", Mark Peterson, Rhino Software, 8-Apr-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-Mar-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. "Channel Bindings for IPsec Using IKEv2 and Public Keys", Nicolas Williams, 21-Mar-08, This document specifies the channel bindings for "IPsec channels" where the peers used the Internet Key Exchange protocol version 2 (IKEv2) and where they used public keys and/or certificates to authenticate each other "Double Flux Defense in the DNS Protocol", John Bambenek, 21-Mar-08, The memo provides information and proposed standards for developers of applications based on the DNS protocol and for administrators of servers and networks. It proposes new standards for DNS and DNSSEC implementations that would prevent abuse of the DNS protocol such as those seen by "Double Flux" service networks. Specifically, this document recommends that all resource records for NS records with Time-To-Live (TTL) settings under 24 hours be dropped as potentially malicious records designed to attack users. This document would update RFCs 1123, 1912, 2181 and 2535. "Humanresolver: an introduction and model of operation", Pars Mutaf, 23-Mar-08, This document introduces "humanresolver": a peer-to-peer contact manager application. "Chrysolite - a backbone bridging solution", Mohammad Yousuf, Matthew Thomas, David Hunter, 24-Mar-08, Chrysolite is a combination of differing technologies to create a wide area BB (Backbone Bridging) architecture. Each Chrysolite switch has a unique MAC address (C-MAC). A link state protocol provides pairwise shortest paths between the C-MACs (one C-MAC per switch). Each switch's C-MAC symbolically represents 2"24 Network N-MACs (with each N-MAC representing one of the endpoints of a P2P VLAN. Using MAT (MAC Address Translation) and setting the locally administered bit in the Ethernet address, Router MAC addresses attached to an edge Chrysolite switch are translated into the end-to-end N-MAC addresses of the P2P circuit that they are attached to. MAT can also be completely avoided by use of a single packet UNI explained below. ALL of the P2P location information for a packet is located in a SINGLE N-MAC address assigned to each end of the P2P VLAN 'circuits'. Using this UNI or MAT backup means that no encapsulation or special headers are required to provide pair-wise shortest paths between the Chrysolite switches. Configuration is restricted to the single unique C-MAC required per Chrysolite switch, and the recording of unique customer VLANs as they are required. "Filename Preservation for EDIINT Protocol", Terry Harding, 24-Mar-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, 25-Mar-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.93)", Andy Boyko, John Kunze, Liz Madden, Justin Littman, 26-Mar-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. "Traversal With Internet Server Transports (TWIST): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Hadriel Kaplan, 26-Mar-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) located behind other NATs. In these situations, it is necessary for the host to use the services of an intermediate node on the Internet that acts as a communication relay. Likewise, if a host of one IP address family wants to communicate with the host of another address family, through one or more NATs, an intermediate node may be necessary. This specification defines a protocol, called TWIST (Traversal With Internet Server Transports), that allows the host to control the operation of a TWIST relay and to exchange packets with its peers using the relay, or directly between each other. This is similar to TURN, but defines an alternative mechanism which is more scalable, cheaper to deploy, and is thus more likely to succeed in achieving wide- spread use. TWIST is not meant to replace TURN, but rather to provide an alternative. This document is a straw-man proposal, to stimulate discussion, not a fully defined draft. "Industrial Routing Requirements in Low Power and Lossy Networks", Dust Networks, Rick Enns, Pascal Thubert, 27-Mar-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. For wireless devices to have a significant advantage over wired devices in an industrial environment the wireless network needs to have three qualities: low power, high reliability, and easy installation and maintenance. The aim of this document is to analyze the requirements for the routing protocol used for low power and lossy networks (L2N) in industrial environments. "LISP Analysis", LISP Authors, 10-Mar-08, This draft answers questions raised in the IRTF Routing Reseach Group Design Goals. A future version may also address issues raised in the IETF Routing Area Problem Statement. "TOTP: Time-based One-time Password Algorithm", David M'Raihi, Salah Machani, Mingliang Pei, Johan Rydell, 27-Mar-08, This document describes an extension of one-time password algorithm HOTP as defined in [RFC4226] to support time based moving factor. "Host Identity Protocol based Mobile Router (HIPMR)", Jan Melen, Jukka Ylitalo, Patrik Salmela, 28-Mar-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. "Pre-Shared Key Cipher Suites for Transport Layer Security with SHA-256/384 and AES Galois Counter Mode", Mohamad Badra, 28-Mar-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 cipher suites for TLS/DTLS which uses stronger digest algorithms (i.e. SHA-256 or SHA-384) and another which uses AES in Galois Counter Mode (GCM). "X.509 Key and Signature Encoding for the KeyNote Trust Management System", Angelos Keromytis, 28-Mar-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 Taxonomy for New Routing and Addressing Architecture Designs", Lixia Zhang, Scott Brim, 29-Mar-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, and then uses the taxonomy to discuss and compare the proposed solutions. "Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.)", Axel Neumann, Corinna Aichele, Marek Lindner, Simon Wunderlich, 30-Mar-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. "Recommendations for filtering ICMP messages", Fernando Gont, Guillermo Gont, 30-Mar-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. "MIPv6 Home Link Detection", Suresh Krishnan, George Tsirtsis, 31-Mar-08, The MIPv6 bootstrapping procedure allows the mobile node to dynamically discover its home prefix using an IKEv2 exchange. Since the home prefix is not statically configured on the mobile node, there is a need to specify a mechanism for the mobile node to detect if it is on its home link. This document specifies one such mechanism. "Passwords in LDAP", Kurt Zeilenga, 31-Mar-08, The Lightweight Directory Access Protocol (LDAP) provides a number of password-based mechanisms for authenticating directory users to the directory service. This document discusses the use of passwords in directory user authentication. The document specifies schema for representing a basic password policy and directory service enforcement of password policy. "Session Initiation Protocol (SIP) Version 4.0: P2P2PSIP", Hadriel Kaplan, Bob Penfield, 1-Apr-08, This document defines a new and improved version of SIP, which tastes great and is less filling than the previous SIP. This draft updates all previous and future RFCs related to SIP in SIPPING, SIMPLE, MMUSIC, BEHAVE, and so on. "Private Header Extension to SIP for Support of Mobility Operations", Michael Coulas, Apostolis Salkintzis, 2-Apr-08, Voice call continuity and media over IP session mobility operations are typically characterized by the movement of a specific segment of a communication session across networks and/or devices. This movement may be implemented through the use of SIP procedures that result in the establishment of a new segment replacing the existing segment. This document proposes a private extension to the Session Initiation Protocol (SIP) that enable User Agents (UA) to indicate that a SIP request is associated with a mobility operation for an existing session. "A Quick Crash Detection Method for IKE", Yoav Nir, 2-Apr-08, This document describes an extension to the IKEv2 protocol that allows for faster crash recovery using a saved token. When an IPsec tunnel between two IKEv2 implementations 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 within a few seconds of the reboot. "IANA Registrations for the 'Send-N' Enumservice", Ray Bellis, 2-Apr-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) enabled applications. "Distributed Internet Archive Protocol (DIAP)", Damian Brasher, 2-Apr-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. "IANA Registration for an Enumservice Subtype "smpp" under Type "sms", and Information and IANA Registration for URI Type "smpp"", James Yu, 3-Apr-08, This document registers an enumservice subtype "smpp" under the existing type "sms" using the URI scheme "smpp" as per the IANA registration process defined in RFC 3761 [2] and draft-ietf-enum- enumservices-guide-07 [6] and registers a new URI type "smpp:" according to the URI registration procedure in RFC 4395 [8]. This enumservice subtype indicates that the remote resource identified by the URI scheme can receive short messages using the Short Message Peer-to-Peer Protocol (SMPP) [7]. "Make-Before-Break Handoffs with Mobile IPv4", Peter McCann, 4-Apr-08, A make-before-break handoff is one where resources on a target system are allocated prior to releasing the resources on a source system. Make-before-break can be an effective means to provide a more seamless handoff with fewer dropped packets. The existing Mobile IPv4 specification supports simultaneous bindings, which can facilitate a make-before-break handoff. However, the binding state at the home agent is only one example of a resource that can be allocated; others include the link connection to the Foreign Agent (or access router) and the provision of security associations between the mobile node and the mobility agents. It may be desirable to set up these resources on the target system without necessarily creating a binding entry on the Home Agent. This document provides some additional conventions on the use of simultaneous bindings in a make- before-break handoff that can be used to optimize the allocation of resources in these scenarios. "MPLS Tunnel Support for Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya, 4-Apr-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. "A Scalable IPv4-IPv6 Transition Architecture Need for an address-port-borrowing-protocol (APBP)", Remi Despres, 7-Apr-08, This document discusses, for the IPv4-IPv6 coexistence period, the combined requirement that: (1) legacy IPv4 hosts can establish IPv4 transport connections 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, 7-Apr-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. "Better Than Nothing Mobile IPv4 Fast Handovers", Alistair Doswald, Stephan Robert, 8-Apr-08, Proposed fast handover solutions for Mobile IPv4 depend on the presence of Foreign Agents (FA) in the networks between which the Mobile Node (MN) moves to ensure their operation. However, in many situations the MN moves into networks without FAs. This document proposes a solution that includes fast handover mechanisms involving a direct connection to the Home Agent (HA). This solution is not a full fledged fast handover proposal, but rather a complement to RFC 4881: Low-Latency Handovers in Mobile IPv4, and RFC 4988: Mobile IPv4 Fast Handover. "Extending 6LowPan to support IPv4 Packets", Harry Courtice, 10-Apr-08, RFC4944 describes header compression formats for IPV6 (HC1) and for TCP, UDP and ICMP (HC2). No compression format is defined for IPV4 headers. This document describes a compression scheme for IPV4 headers which closely follows the IPV6 header compression format HC1 described in RFC4944. "A Default Route for DYMO", Ian Chakeres, 10-Apr-08, This document describes how to distribute, create, and update a default route in DYMO. "Generic Notification Message for Mobile IPv6", Brian Haley, Sri Gundavelli, 10-Apr-08, This document specifies a new Mobility Header message type that allows Mobile IPv6 entities to send and receive generic notification messages. Haley Expires - April 2008 [page 1] Generic Notification Message for Mobile IPv6 October 2008 "Transport Layer Security (TLS) Authorization Using KeyNote", Angelos Keromytis, 28-Aug-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. 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, 15-Feb-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, 4-Feb-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. "QoS NSLP QSPEC Template", Gerald Ash, Attila Bader, Cornelia Kappler, David Oran, 4-Apr-08, The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. The node initiating the NSIS signaling adds an initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. "Applicability Statement of NSIS Protocols in Mobile Environments", Sung-Hyuck Lee, 25-Feb-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, 14-Nov-07, 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, 25-Feb-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, 25-Feb-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, 4-Mar-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, 20-Feb-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, and the support of multi-homing to provide network level fault tolerance. Additionally, the support for the Partial Reliability Extension of SCTP is discussed. Network Time Protocol (ntp) --------------------------- "Network Time Protocol Version 4 Protocol And Algorithms Specification", Jack Burbank, 25-Feb-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, 25-Feb-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, 25-Feb-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. An Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------------- "The Camellia Cipher in OpenPGP", David Shaw, 22-Jan-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) ----------------------------------------------------- "Simple Network Management Protocol (SNMP) Context EngineID Discovery", , 13-Feb-08, The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application knows the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity. This document introduces a well-known localEngineID and a discovery mechanism which can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects. This document updates RFC 3411. "Guidelines for Considering Operations and Management of New Protocols", David Harrington, 25-Feb-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, covering aspects of operations and management that should be considered. "Expressing SNMP SMI Datatypes in XML Schema Definition Language", Bob Natale, Yan Li, 25-Feb-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 production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. "A Template for Internet Drafts Containing Data Models", David Harrington, 11-Feb-08, This memo contains two annotated templates for IETF documents that contain the definition of data models. It is intended to alleviate the work of the authors of such documents, making these more uniform and easier to read and review, thus furthering the quality of such documents and expediting their publication. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Security Best Practices Efforts and Documents", Chris Lonvick, David Spak, 17-Dec-07, This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). 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, 13-Feb-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. "Traffic Engineering Extensions to OSPF version 3", Kunihiro Ishiguro, 26-Mar-08, This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. "Support of address families in OSPFv3", Sina Mirtorabi, 7-Nov-07, 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. "OSPF Multi-Area Adjacency", Sina Mirtorabi, 2-Apr-08, This document describes an extension to OSPF to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra-area path to the corresponding areas sharing the same link. "Advertising a Router's Local Addresses in OSPF TE Extensions", Rahul Aggarwal, Kireeti Kompella, 19-Nov-07, This document describes procedures that enhance OSPF Traffic Engineering (TE) extensions for advertising a router's local addresses. This is needed to enable other routers in a network to compute traffic engineered MPLS LSPs to a given router's local addresses. Currently, 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. "OSPFv3 Graceful Restart", Padma Pillay-Esnault, Acee Lindem, 19-Oct-07, This document describes the OSPFv3 graceful restart. The OSPFv3 graceful restart is identical to OSPFv2 except for the differences described in this document. These differences include the format of the grace Link State Advertisements (LSA) and other considerations. "OSPF for IPv6", Dennis Ferguson, 7-Apr-08, This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload. Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs) are also supported in OSPF for IPv6. "The OSPF Opaque LSA Option", Lou Berger, Igor Bryskin, Alex Zinin, 10-Mar-08, This document defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology. This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate AS-scope opaque LSAs originated outside of the router's OSPF area. "OSPF Database Exchange Summary List Optimization", Richard Ogier, 11-Dec-07, This document describes a backward compatible optimization for the Database Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list an LSA in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reduces Database Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets. "OSPF Version 2 MIB for Multi-Topology (MT) Routing", Namita Rawat, 1-Apr-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, 25-Jan-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, 7-Feb-08, This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, enhanced with MANET techniques based on multi-point relaying (MPR). "Extensions to OSPF to Support Mobile Ad Hoc Networking", M Chandra, Abhay Roy, 11-Feb-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. "MANET Extension of OSPF using CDS Flooding", Richard Ogier, Phil Spagnolo, 16-Feb-08, This document specifies an extension of OSPF for IPv6 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new LSAs back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. Peer-to-Peer Session Initiation Protocol (p2psip) ------------------------------------------------- "Concepts and Terminology for Peer to Peer SIP", David Bryan, Philip Matthews, Eunsoo Shim, Dean Willis, 15-Nov-07, 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 that might be 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. Protocol for carrying Authentication for Network Access (pana) -------------------------------------------------------------- "Protocol for Carrying Authentication for Network Access (PANA)", Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, Alper Yegin, 6-Sep-07, This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP- based EAP lower layer that runs between the EAP peer and the EAP authenticator. "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. "Protocol for Carrying Authentication for Network Access (PANA) Framework", Prakash Jayaraman, Yoshihiro Ohba, Mohan Parthasarathy, Alper Yegin, 6-Sep-07, This document defines the general PANA framework functional elements, high-level call flow, and deployment environments. "State Machines for Protocol for Carrying Authentication for Network Access (PANA)", Victor Fajardo, 15-Oct-07, 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, 18-Nov-07, This document defines an extension to the PANA protocol used for proactively establishing a PANA SA (Security Association) between a PaC in an access network and a PAA in another access network to which the PaC may move. The proposed method operates across multiple administrative domains. Path Computation Element (pce) ------------------------------ "Path Computation Element (PCE) Communication Protocol (PCEP)", Arthi Ayyangar, Eiji Oki, Alia Atlas, Andrew Dolganow, Yuichi Ikejiri, Kenji Kumaki, JP Vasseur, Jean-Louis Le Roux, 25-Mar-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, 9-Apr-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", Eiji Oki, 21-Jan-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, 1-Nov-07, 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.Contents "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", Nabil Bitar, 22-Feb-08, Multiprotocol Label Switching Traffic Engineered (MPLS-TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries. The Path Computation Element (PCE) is a component that is capable of computing paths for MPLS-TE LSPs. The PCE Communication Protocol(PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, and between PCEs. The PCECP is used to request paths and to supply computed paths in response. Generic requirements for the PCECP are set out in "Path Computation Element(PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLS-TE. "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, 2-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, 14-Feb-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. "Inclusion of Manageability Sections in PCE Working Group Drafts", Adrian Farrel, 19-Feb-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", Eiji Oki, Adrian Farrel, 25-Mar-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, 24-Feb-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. 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, 21-Feb-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. 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 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 Global Concurrent Optimization is able to simultaneously consider the entire topology of the network and the complete set of existing LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all LSPs. The Global Concurrent Optimization (GCO) application is primarily an NMS based solution. This document provides application-specific requirements and the PCEP extensions in support of a global concurrent optimization (GCO) application. "Encoding of Objective Functions in Path Computation Element communication Protocol (PCEP)", Jean-Louis Le Roux, 27-Feb-08, The computation of one or a series 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(s), referred to as an objective function (e.g. minimum cost path, widest path, etc.). A Path Computation Element (PCE) may support one or multiple objective functions, and it is desired for a Path Computation Client (PCC) to automatically discover the set of objective functions supported by a PCE. Furthermore, it may be useful for a PCC to specify in a path computation request the required objective function to be used by the PCE to compute a TE LSP or a set of TE LSPs. Thus the aim of this document is to define extensions to the PCE communication Protocol (PCEP) in order to allow a PCC to discover the set of objective functions supported by a PCE as well as to allow a PCC to indicate in a path computation request the required objective function and a PCE to indicate 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, 6-Feb-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 is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems). 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, 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, Kenji Kumaki, 23-Oct-07, 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, 18-Feb-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. Oki, Le Roux, and Farrel [page 1] PCEP Extensions for Inter-Layer TE February 2008 Congestion and Pre-Congestion Notification (pcn) ------------------------------------------------ "Pre-Congestion Notification Architecture", Philip Eardley, 7-Feb-08, The purpose of this document is to describe 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 Protocol Independent Multicast (pim) ------------------------------------ "The RPF Vector TLV", IJsbrand Wijnands, 22-Feb-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. "Format for using TLVs in PIM messages", A Boers, 21-May-07, This document describes a generic TLV attribute encoding format to be added to PIM join messages. "PIM Bootstrap Router MIB", Bharat Joshi, Raina Bijlani, 25-Oct-07, This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Bootstrap Router (BSR) mechanism for PIM. "Authentication and Confidentiality in PIM-SM Link-local Messages", John Atwood, Salekul Islam, Maziar Siami, 25-Feb-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. "Host Threats to Protocol Independent Multicast (PIM)", Pekka Savola, James Lingard, 10-Oct-07, This memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol Independent Multicast (PIM) threats specific to router interfaces connecting hosts. Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Certificate Management Messages over CMS", Jim Schaad, Michael Myers, 10-Mar-08, This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and 2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design. CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. "Certificate Management over CMS (CMC): Transport Protocols", Jim Schaad, Michael Myers, 10-Mar-08, This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are: HTTP, file, mail and TCP. "Certificate Managmement Messages over CMS (CMC): Complience Requirements", Jim Schaad, Michael Myers, 4-Dec-07, This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Dave Cooper, 13-Feb-08, This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. "Elliptic Curve Cryptography Subject Public Key Information", Sean Turner, Kelvin Yiu, Daniel R. L. Brown, Russ Housley, William Polk, 11-Mar-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 RFC 3279. "Trust Anchor Management Problem Statement", Raksha Reddy, Carl Wallace, 18-Feb-08, 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 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 as well as problems that must be addressed by such a mechanism. This document discusses only public keys as trust anchors; symmetric key trust anchors are not considered. "New ASN.1 Modules for PKIX", Paul Hoffman, Jim Schaad, 21-Dec-07, 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, 23-Jan-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. Performance Metrics for Other Layers (pmol) ------------------------------------------- "SIP End-to-End Performance Metrics", Daryl Malas, 25-Feb-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. Packet Sampling (psamp) ----------------------- "A Framework for Packet Selection and Reporting", Nick Duffield, 28-Jun-07, 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. Comments on this document should be addressed to the PSAMP Working Group mailing list: psamp@ops.ietf.org To subscribe: psamp-request@ops.ietf.org, in body: subscribe Archive: https://ops.ietf.org/lists/psamp/ "Sampling and Filtering Techniques for IP Packet Selection", Tanja Zseby, 19-Jun-07, 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, 22-Feb-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)", Thomas Nadeau, 22-Feb-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-Dec-07, 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, 22-Feb-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. "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", Matthew Bocci, Luca Martini, 17-Dec-07, This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains. "Segmented Pseudo Wire", Luca Martini, 25-Feb-08, This document describes how to connect pseudo wires (PW) between two distinct PW control planes or PSN domains. The PW control planes may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. "Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks", Sasha Vainshtein, Yaakov Stein, 20-Mar-08, This document defines extension to the PWE3 control protocol [RFC4447] and PWE3 IANA allocations [RFC4446] required for setup of TDM pseudowires in MPLS networks. "Dynamic Placement of Multi Segment Pseudo Wires", Florin Balus, 19-Nov-07, 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. "Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks", Moran Roth, 17-Jan-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. "Application of Ethernet Pseudowires to MPLS Transport Networks", Stewart Bryant, Monique Morrow, George Swallow, Thomas Nadeau, Neil Harrison, 7-Feb-08, A requirement has been identified by the operator community for the transparent carriage of the MPLS network of one party over the MPLS network of another party. This document describes an IETF- recommended method of satisfying this need using the existing RFC4448 PWE3 Ethernet pseudowire standard. "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Thomas Nadeau, Carlos Pignataro, 25-Feb-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, Mustapha Aissaoui, Matthew Bocci, Pranjal Dutta, Marc Lasserre, 25-Feb-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, 28-Mar-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. RADIUS EXTensions (radext) -------------------------- "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", David Nelson, Greg Weber, 24-Feb-08, This document describes Remote Authentication Dial-In User Service (RADIUS) attributes for the authorization and service provisioning of local and remote management of embedded systems and other managed entities, generally referred to as Network Access Servers (NASes). Specific provisions are made for remote management via framed management protocols, for granular levels of access rights and management privileges, and for specification of a protected transport protocol. "RADIUS Design Guidelines", Greg Weber, Alan DeKok, 5-Dec-07, 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, 15-Mar-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. Reliable Multicast Transport (rmt) ---------------------------------- "Layered Coding Transport (LCT) Building Block", Michael Luby, Mark Watson, Lorenzo Vicisano, 16-Nov-07, 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, 16-Nov-07, 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, 16-Nov-07, This document provides FEC Scheme specifications according to the RMT FEC Building Block for the Compact No-Code FEC Scheme, the Small Block, Large Block and Expandable FEC Scheme, the Small Block Systematic FEC Scheme and the Compact FEC Scheme. "FLUTE - File Delivery over Unidirectional Transport", Toni Paila, 29-Oct-07, This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. "Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes", Vincent Roca, Christoph Neumann, David Furodet, 23-Jan-08, This document describes two Fully-Specified FEC Schemes, LDPC- Staircase and LDPC-Triangle, and their 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). These systematic FEC codes belong to the well known class of ``Low Density Parity Check'' (LDPC) codes, and are large block FEC codes in the sense of RFC3453. "NACK-Oriented Reliable Multicast (NORM) Protocol", Brian Adamson, 15-Jan-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, 2-Apr-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. "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, 25-Feb-08, This document describes some security risks of 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 discussion and potential resolution of any significant security issues that may exist in the current set of RMT standards. Robust Header Compression (rohc) -------------------------------- "Integration of Robust Header Compression (RoHC) over IPsec Security Associations", Emre Ertekin, 4-Jan-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). "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite", Ghyslain Pelletier, Kristofer Sandlund, 19-Mar-08, This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers. This specification defines a second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them. The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define its own specific set of header formats, using the ROHC formal notation. "IKEv2 Extensions to Support Robust Header Compression over IPsec (RoHCoIPsec)", Rohan Jasani, 4-Jan-08, When using Robust Header Compression (RoHC [ROHC]) in conjunction with IPsec [IPSEC] (i.e. [RoHCOIPSEC]) a mechanism is needed to negotiate RoHC configuration parameters between end-points prior to operation. Internet Key Exchange (IKE) is a mechanism which can be leveraged to handle these negotiations. This document specifies extensions to Internet Key Exchange (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, 4-Jan-08, Integrating RoHC with IPsec (RoHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. Before this can be realized, however, several extensions to the Security Policy Database (SPD), the Security Association Database (SAD), and the IPsec process are required. This document describes the IPsec extensions required to support RoHCoIPsec. Routing Protocol Security Requirements (rpsec) ---------------------------------------------- "BGP Security Requirements", Blaine Christian, Tony Tauber, 19-Nov-07, The security of BGP, the Border Gateway Protocol, is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routing system, is more complex. This document describes a set of requirements for securing BGP, including communications between BGP speakers, and the routing information carried within BGP. "BGP Session Security Requirements", Michael Behringer, 12-Dec-07, 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) ---------------------------------- "Aggregate Server Access Protocol (ASAP)", Randall Stewart, Qiaobing Xie, Maureen Stillman, Michael Tuexen, 28-Mar-08, Aggregate Server Access Protocol (ASAP) in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP) [I-D.ietf-rserpool-enrp] provides a high availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model which isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es) which normally constitutes a single point of failure. In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server-pooling and load sharing. It also allows dynamic system scalability - members of a server pool can be added or removed at any time without interrupting the service. ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP) [RFC4960]. Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between PE's and ENRP servers MUST use the SCTP transport protocol. The high availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for pool handle to address translation, load sharing management, and fault management while ENRP defines the high availability pool handle translation service. "Endpoint Handlespace Redundancy Protocol (ENRP)", Dae Young Kim, Randall Stewart, Maureen Stillman, Michael Tuexen, Aron Silverton, 28-Mar-08, The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", Randall Stewart, Qiaobing Xie, Maureen Stillman, Michael Tuexen, 27-Mar-08, This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) protocols defined within the Reliable Server Pooling (RSerPool) architecture. "Reliable Server Pooling: Management Information Base using SMIv2", Jaiwant Mulik, Thomas Dreibholz, 10-Jan-08, RSerPool [2] is a framework to provide reliable server pooling. This document defines a SMIv2 compliant Management Information Base (MIB) providing access to managed objects in an RSerPool implementation. "Threats Introduced by RSerPool and Requirements for Security in Response to Threats", Maureen Stillman, Ram Gopal, Erik Guttman, Matt Holdrege, Senthil Sengodan, 24-Oct-07, Rserpool is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This Internet draft describes security threats to the Rserpool architecture and presents requirements for security to thwart these threats. "Reliable Server Pooling Policies", Michael Tuexen, Thomas Dreibholz, 10-Mar-08, This document describes server pool policies for Reliable Server Pooling including considerations for implementing them at ENRP servers and pool users. "An Overview of Reliable Server Pooling Protocols", Peter Lei, Lyndon Ong, Michael Tuexen, Thomas Dreibholz, 22-Feb-08, The Reliable Server Pooling effort (abbreviated "RSerPool"), provides an application-independent set of services and protocols for building fault tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the reliable server pooling suite. Routing Area Working Group (rtgwg) ---------------------------------- "IP Fast Reroute Framework", Mike Shand, Stewart Bryant, 25-Feb-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. "Basic Specification for IP Fast-Reroute: Loop-free Alternates", Alex Zinin, Raveendra Torvi, G Choudhury, Christian Martin, Brent Imhoff, Don Fedyk, 27-Mar-08, This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. "Loop-free convergence using oFIB", Pierre Francois, 25-Feb-08, This draft describes a mechanism for use in conjunction with link state routing protocols which prevents the transient loops which would otherwise occur during topology changes. It does this by correctly sequencing the FIB updates on the routers. This mechanism can be used in the case of non-urgent link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a FRR mechanism which converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations. After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described. "IP Fast Reroute Using Not-via Addresses", Mike Shand, Stewart Bryant, Stefano Previdi, 25-Feb-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, 14-Feb-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. Site Multihoming by IPv6 Intermediation (shim6) ----------------------------------------------- "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Jari Arkko, Iljitsch van Beijnum, 13-Feb-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, 22-Feb-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, 23-Feb-08, This document specifies a socket API for the multihoming shim layer. The API aims to enable interactions between the 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 sublayer (here after "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, 13-Nov-07, This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-to-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", Karen Seo, 25-Feb-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 Internet IP Address and AS Number (PKI)", Stephen Kent, 25-Feb-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)", Dennis Kong, 25-Feb-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)", Stephen Kent, 25-Feb-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, Richard Barnes, 25-Feb-08, This document describes an architecture for an infrastructure to support secure 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; certificates from this PKI are used to verify signed objects that authorize autonomous systems to originate routes for specified IP address prefixes. The data objects that comprise the PKI, as well as other signed objects necessary for secure routing, are stored and disseminated through a distributed repository system. This document also describes at a high level how this architecture can be used to add security features to common operations such as IP address space allocation and route filter construction. "A Protocol for Provisioning Resource Certificates", Geoff Huston, Robert Loomans, Byron Ellacott, Rob Austein, 1-Jan-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, 2-Jan-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 threats to relying parties of the results of a man-in-the middle withholding attack on repository retrieval operations. Sieve Mail Filtering Language (sieve) ------------------------------------- "Sieve Email Filtering: Body Extension", Philip Guenther, Jutta Degener, 20-Mar-08, This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. "Sieve Email Filtering: Editheader Extension", Philip Guenther, Jutta Degener, 21-Mar-08, This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. "Sieve Email Filtering: Extensions for Rejecting Messages", Aaron Stone, Mathew Elley, Alexey Melnikov, 14-Dec-07, 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. The "ereject" action is intended to replace the "reject" action wherever possible. "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, 18-Mar-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, 23-Feb-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. SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- "Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information", Mikko Lonnfors, Jose Costa-Requena, Eva Leppanen, Hisham Khartabil, 21-Jan-08, By default, presence delivered using the Presence Event Package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. "Presence Information Data format (PIDF) Extension for Partial Presence", Mikko Lonnfors, Eva Leppanen, Hisham Khartabil, Jari Urpalainen, 19-Nov-07, The Presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type which enables transporting of either only the changed parts or the full PIDF based presence information. "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Mikko Lonnfors, Krisztian Kiss, 18-Mar-08, Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant Presence protocols. This memo defines an extension to represent SIP User Agent capabilities in the Presence Information Document Format (PIDF) compliant presence documents. "Publication of Partial Presence Information", Aki Niemi, Mikko Lonnfors, Eva Leppanen, 20-Feb-08, The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitue a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. "An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources", Jonathan Rosenberg, Jari Urpalainen, 24-Feb-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. "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", Jari Urpalainen, 16-Nov-07, Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic , and directives a set of patches can then be applied to update an existing XML document. "Instant Message Disposition Notification", Eric Burger, Hisham Khartabil, 1-Apr-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 read 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, 25-Feb-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 Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP)", Aki Niemi, Miguel Garcia-Martin, Geir Arne Sandbakken, 4-Feb-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 instant messaging (IM) sessions, or chat rooms, with MSRP. "SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 24-Feb-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, 21-Feb-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 Federation", Jonathan Rosenberg, Avshalom Houri, 21-Feb-08, Presence federation involves the sharing of presence information across multiple presence systems. Most often, presence federation is assumed to be between different organizations, such as between two enterprises or between and enterprise and a service provider. However, federation can occur within a single organization or domain. This 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 federation. Session Initiation Protocol (sip) --------------------------------- "Connection Reuse in the Session Initiation Protocol (SIP)", Rohan Mahy, Vijay Gurbani, Brett Tate, 8-Feb-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 should be 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. A single connection cannot be reused for the TCP or SCTP transport between two peers, and this document provides insight 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, 25-Feb-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 proxy servers make routing decisions based on the location of the SIP user agents. "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Cullen Jennings, Rohan Mahy, 21-Mar-08, The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs), prevent servers from connecting to User Agents in this way. 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, 6-Sep-07, This document defines 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, 3-Nov-07, 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, 5-Apr-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, 18-Nov-07, 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, 24-Feb-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 the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. "A Framework for Consent-based Communications in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, Gonzalo Camarillo, Dean Willis, 31-Jan-08, The Session Initiation Protocol (SIP) supports communications for several services, including, real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification, and DoS (Denial of Service) attacks. This document identifies a framework for consent- based communications in SIP. "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Adam Roach, Orit Levin, 13-Nov-07, This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' state using a single SUBSCRIBE dialog. "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", Miguel Garcia-Martin, Gonzalo Camarillo, 21-Dec-07, This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list. "Referring to Multiple Resources in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Aki Niemi, Markus Isomaki, Miguel Garcia-Martin, Hisham Khartabil, 18-Dec-07, This document defines extensions to the SIP REFER method so that this method can be used to refer to multiple resources in a single request. These extensions include the use of pointers to Uniform Resource Identifier (URI)-lists in the Refer-To header field and the "multiple-refer" SIP option-tag. "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Alan Johnston, 13-Nov-07, This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a user agent client to provide a conference server with the initial list of participants using an INVITE-contained URI-list. "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, 25-Feb-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, 22-Feb-08, A typical function of a Session Initiation Protocol (SIP) Proxy is to set a Record-Route header on initial requests in order to make subsequent 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 like different transport parameters (UDP, TCP, SCTP...), 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, sip to sips 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, 23-Jan-08, This document specifies how message bodies are handled in SIP. Additionally, it 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, 20-Mar-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, 13-Mar-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, 18-Feb-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, 8-Nov-07, This document describes how to interpret certain information in a X.509 PKIX-compliant certificate used in a Transport Layer Security (TLS) connection. More specifically, it describes how to find the right identity for authentication in such certificates and how to use it for mutual authentication. "Framework for Establishing an SRTP Security Context using DTLS", Jason Fischl, Hannes Tschofenig, Eric Rescorla, 24-Feb-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. It relies on the SIP identity mechanism to ensure the integrity of the fingerprint attribute. The key exchange travels along the media path as opposed to the signaling path. "UA-Driven Privacy Mechanism for SIP", Mayumi Munakata, Shida Schubert, Takumi Ohba, 18-Feb-08, To withhold a user's identity and related information, RFC 3323 defines a Privacy mechanism for SIP, which requires the use of an privacy service. This document proposes a new privacy mechanism that a user agent can facilitate to conceal privacy-sensitive information without the need for aid from a privacy service. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package", Jari Urpalainen, 24-Feb-08, This document describes an "xcap-diff" SIP event package, with the aid of which clients can receive notifications of the partial changes of Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization and document updates are based on using the XCAP-Diff format. "Essential correction for IPv6 ABNF and URI comparison in RFC3261", Vijay Gurbani, Brian Carpenter, Brett Tate, 15-Feb-08, This memo corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. Session Initiation Proposal Investigation (sipping) --------------------------------------------------- "Session Initiation Protocol Service Examples", Alan Johnston, Robert Sparks, Chris Cunningham, Steve Donovan, Kevin Summers, 19-Feb-08, This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP User Agents, although some require the assistance of a SIP Proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Rohan Mahy, 5-Dec-07, This document defines a framework and requirements for multi-party usage of SIP. To enable discussion of multi-party features and applications we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually setup the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state, and session history. This framework also describes other goals that embody the spirit of SIP applications as used on the Internet. "Session Initiation Protocol Call Control - Transfer", Robert Sparks, 14-Dec-07, 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. "Framework for Transcoding with the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 1-Dec-06, This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services", Gonzalo Camarillo, Adam Roach, 13-Nov-07, This document describes the need for SIP URI-list services and provides requirements for their invocation. Additionaly, it defines a framework for SIP URI-List services, which includes security considerations applicable to these services. "Framework for real-time text over IP using the Session Initiation Protocol (SIP)", Arnoud Van Wijk, Guido Gybels, 4-Apr-08, This document lists the essential requirements for real-time Text- over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the PSTN and other networks. "The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model", Gonzalo Camarillo, 6-Jun-06, This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. "IPv6 Transition in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 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, 19-Nov-07, 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", Amy Pendleton, 2-May-07, This document defines a SIP event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists", Miguel Garcia-Martin, Gonzalo Camarillo, 18-Dec-07, In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI-list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing e-mail systems. "A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies", Volker Hilt, Gonzalo Camarillo, 24-Aug-07, This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents to subscribe to session policies for a SIP session and to receive notifications if these policies change. "The Session Initiation Protocol (SIP) Pending Additions Event Package", Gonzalo Camarillo, 15-Feb-08, This document defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list. "A Document Format for Requesting Consent", Gonzalo Camarillo, 15-Feb-08, This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation. "Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments", Jani Hautakorpi, Gonzalo Camarillo, Bob Penfield, Alan Hawrylyshen, Medhavi Bhatia, 25-Mar-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, 25-Jan-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", Takuya Sawada, Paul Kyzivat, 2-Apr-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, 18-Feb-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, 24-Feb-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 several perils associated with service identification, 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, 11-Feb-08, The document provides a set of requirements for enabling interdomain scaling in presence for SIP/SIMPLE. The requirements are based on a separate scaling analysis document. "Updates to Asserted Identity in the Session Initiation Protocol (SIP)", John Elwell, 4-Apr-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 this header field with the SIP UPDATE, REGISTER, MESSAGE or PUBLISH methods, and is unclear on the use of this header field in responses. 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", Sumanth Channabasappa, Sam Ganesan, Volker Hilt, 15-Feb-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. S/MIME Mail Security (smime) ---------------------------- "CMS Symmetric Key Management and Distribution", Sean Turner, 28-Jan-08, This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses the Cryptographic Message Syntax (CMS) protocol [CMS] and Certificate Management Message over CMS (CMC) protocol [CMC] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). "Use of the RSA-KEM Key Transport Algorithm in CMS", James Randall, Burton Kaliski, 19-Oct-07, 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", Mark Schertler, 8-Nov-07, 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. "Using the Boneh-Franklin and Boneh-Boyen identity-based encryption algorithms with the Cryptographic Message Syntax (CMS)", Luther Martin, Mark Schertler, 8-Nov-07, 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, 11-Mar-08, This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", Sean Turner, Blake Ramsdell, 21-Feb-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 3280bis, 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 3280bis. This document obsoletes RFC 3850. "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", Blake Ramsdell, Sean Turner, 13-Mar-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, 21-Dec-07, 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. "Update to Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", Sean Turner, 1-Apr-08, RFC 3278 describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). This document updates RFC 3278 to add support for the SHA2 family of hash algorithms. Softwires (softwire) -------------------- "Softwire Hub & Spoke Deployment Framework with L2TPv2", Bill Storer, Carlos Pignataro, Maria Santos, Bruno Stevant, Jean-Francois Tremblay, 29-Jan-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, 25-Feb-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, 31-Mar-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, 18-Jan-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. "Traffic Engineering Attribute", Hamid Ould-Brahim, 23-Jan-08, This document defines a new BGP attribute, Traffic Engineering attribute, than enables BGP to carry Traffic Engineering information. "BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute", Pradosh Mohapatra, Eric Rosen, 24-Jan-08, In certain situations, transporting a packet from one 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 L2TPv3, 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 SAFI" and IPv4 or IPv6 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 UPDATE messages that carry payload prefixes to indicate the encapsulation protocol type to be used. "BGP IPSec Tunnel Encapsulation Attribute", Lou Berger, Eric Rosen, Russ White, 10-Mar-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, 21-Dec-07, 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, 12-Feb-08, This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). "SPEERMINT Requirements for SIP-based VoIP Interconnection", Jean-Francois Mule, 25-Feb-08, A number of use cases have been described for session peering of voice, presence, instant messaging and other types of multimedia traffic. This memo captures some of the requirements identified by these use case scenarios. It is intended to become an informational document linking the use cases to potential protocol solutions. "SPEERMINT Peering Architecture", Reinaldo Penno, 25-Feb-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. "Use of DNS SRV and NAPTR Records for SPEERMINT", Tom Creighton, Jason Livingood, 9-Nov-07, 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. "Presence & Instant Messaging Peering Use Cases", Avshalom Houri, 19-Feb-08, The document describes several use cases of peering of non-VoIP services between two or more Service Providers. These Service Providers create a peering relationship between themselves thus enabling their users to collaborate with users on the other Service Provider network. The target of the document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services and presence and Instant Messaging (IM) in particular. "VoIP SIP Peering Use Cases", Adam Uzelac, Yiu Lee, 10-Apr-08, This document depicts many common VoIP use case for 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. This document captures them to provide a reference. 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". "Syslog Management Information Base", Glenn Mansfield, 12-Feb-08, This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog applications. "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, 17-Nov-07, 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, 13-Feb-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. "Reliable Delivery for syslog", Darren New, Marshall T. Rose, Eliot Lear, 8-Nov-07, The syslog protocol describes a number of service options related to propagating event messages. This memo describes a mapping of the syslog protocol to TCP connections, useful for reliable delivery of event messages through the use of a BEEP profile. The earlier RAW and COOKED BEEP syslog profiles are deprecated. The use of syslog over BEEP provides robustness and security in message delivery that is unavailable to the usual UDP-based syslog protocol, by providing encryption and authentication over a connection-oriented protocol. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- "Improving TCP's Robustness to Blind In-Window Attacks", Anantha Ramaiah, 8-Jan-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 to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a RST, SYN or DATA segment 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 either abort or possibly 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, 19-Nov-07, 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, 19-Feb-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 TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to a report of an ECN-marked SYN/ACK packet by reducing its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. This document is intended to update RFC 3168. "TCP's Reaction to Soft Errors", Fernando Gont, 26-Dec-07, 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, 14-Mar-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, 18-Nov-07, 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, 12-Nov-07, This document specifies a TCP Authentication Option (TCP-AO) which is intended to replace the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs) and provides more details on the association of security associations with TCP connections. TCP-AO assumes an external, out- of-band mechanism (manual or via a separate protocol) for session key establishment, parameter negotiation, and rekeying, replicating the separation of key management and key use as in the IPsec suite. The result is intended to be a simple modification to support current infrastructure uses of TCP MD5, such as to protect BGP and LDP, and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a new option identifier, even though it is intended to be mutually exclusive with TCP MD5 on a given TCP connection. It supports IPv6, and is fully compatible with requirements under development for an update to TCP MD5. "TCP Extensions for High Performance", David Borman, Robert Braden, Van Jacobson, 29-Jan-08, This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences). Selective acknowledgments are not included in this memo. This memo updates and obsoletes RFC-1323 [Jacobson92d]. Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- "TICTOC Problem Statement", Stewart Bryant, Yaakov Stein, 9-Apr-08, This Internet draft describes a number of applications that require accurate time and/or frequency, and elucidates difficulties related to the transfer of high quality time and frequency across an IP or MPLS Packet Switched Network. This issue is not addressed by any currently chartered IETF working group, and we therefore propose the formation of a new working group to be called Transmitting Timing over IP Connections and Transfer of Clock (TICTOC). "TICTOC Modules", Yaakov Stein, Stewart Bryant, 9-Apr-08, This Internet draft proposes the modularization of TICTOC (Transmitting Timing over IP Connections and Transfer of Clock) work. In particular, it breaks the work down into individual modules (deliverables) that need to be developed. Transport Layer Security (tls) ------------------------------ "The Transport Layer Security (TLS) Protocol Version 1.2", Tim Dierks, Eric Rescorla, 26-Mar-08, This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode", Eric Rescorla, 12-Feb-08, RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm. This document describes eight new CipherSuites for TLS/DTLS which specify stronger digest algorithms. Four use HMAC with SHA-256 or SHA-384 and four use AES in Galois Counter Mode (GCM). "AES-GCM Cipher Suites for TLS", Joseph Salowey, Abhijit Choudhury, David McGrew, 8-Feb-08, This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS ciphersuites that use AES-GCM with RSA, DSS and Diffie-Hellman based key exchange mechanisms. "Transport Layer Security (TLS) Extensions: Extension Definitions", Donald Eastlake 3rd, 25-Feb-08, This document provides documentation for existing specific TLS extensions. It is a companion document for the TLS 1.2 specification, draft-ietf-tls-rfc4346-bis-07.txt. "Keying Material Extractors for Transport Layer Security (TLS)", Eric Rescorla, 20-Feb-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, 2-Apr-08, This document extends RFC 4279, RFC 4492 and RFC 4785, and specifies a set of ciphersuites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange (ECDH). These ciphersuites provide Perfect Forward Secrecy (PFS). "DES and IDEA Cipher Suites for Transport Layer Security (TLS)", Pasi Eronen, 10-Mar-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 NNNN). This document specifies these cipher suites for completeness, and discusses reasons why their use is no longer recommended. Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- "Rbridges: Base Protocol Specification", Radia Perlman, 25-Feb-08, RBridges allow for optimal pair-wise forwarding with zero configuration, safe forwarding even during periods of temporary loops, and multipathing for 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 bridges as well as current 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 based on RBridge destinations (rather than end node destinations), which allows internal forwarding tables to be substantially smaller than in conventional bridge systems. "Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement", Joseph Touch, Radia Perlman, 24-Feb-08, Current Ethernet (802.1) link layers use custom routing protocols that have a number of challenges. The routing protocols need to strictly avoid loops, even temporary loops during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non- overlapping pairwise paths (in the case of spanning trees). The convergence of these routing protocols and stability under link changes and failures is also of concern. This document addresses these concerns and suggests that they are related to the need to be able to apply 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.1D) links, but that a solution would be backward compatible with 802.1D, including hubs, bridges, and their existing plug-and-play capabilities. This document is a work in progress; we invite you to participate on the mailing list at http://www.postel.org/rbridge "The Architecture of an RBridge Solution to TRILL", Eric Gray, Joseph Touch, Radia Perlman, 25-Feb-08, RBridges are link layer (L2) devices that use a routing protocol as a control plane. This combines several of the benefits of the link layer with those of the network layer. For example RBridges use existing link state routing, without necessarily requiring configuration, to improve aggregate throughput, for RBridge to RBridge traffic. RBridges also may support IP multicast and IP address resolution optimizations. They are intended to be applicable to L2 network sizes similar to those of conventional bridges and are intended to be backward compatible with those bridges as both ingress/egress and transit. They also support VLANs (although this generally requires configuration) while otherwise attempting to retain as much 'plug and play' as is already available in existing bridges. This document proposes an architecture for RBridge systems as a solution to the TRILL problem, defines terminology, and describes basic components and desired behavior. One (or more) separate documents will specify protocols and mechanisms that satisfy the architecture presented herein. Transport Area Working Group (tsvwg) ------------------------------------ "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Randall Stewart, Qiaobing Xie, TimeSys Corp, Kacheong Poon, Michael Tuexen, Vladislav Yasevich, 24-Feb-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, 31-Mar-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 RSVP extensions 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. "DSCPs for Capacity-Admitted Traffic", Fred Baker, James Polk, Martin Dolly, 24-Feb-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. It 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, 18-Dec-07, 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, 14-Dec-07, RSVP signaling 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. 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. This document presents RSVP Proxy behaviors allowing RSVP routers to perform RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on critical parts 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. "User-Defined Errors for RSVP", George Swallow, Adrian Farrel, 5-Apr-08, The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP. This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors. "UDP Usage Guidelines for Application Designers", Lars Eggert, Gorry Fairhurst, 3-Apr-08, The User Datagram Protocol (UDP) provides a minimal, message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of such applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums and middlebox traversal. "Port Randomization", Michael Larsen, Fernando Gont, 25-Feb-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 simple and efficient method for 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 mechanisms described in this document are a local modification that may be incrementally deployed, and that does not violate the specifications of any of the transport protocols that may benefit from it, such as TCP, UDP, SCTP, DCCP, and RTP. "Applicability of Keying Methods for RSVP Security", Michael Behringer, Francois Le Faucheur, 18-Feb-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. Draft-weis-gdoi-for-rsvp provides an example of how the Group Domain of Interpretation (GDOI) could be used to distribute group keys to RSVP nodes. The present document also discusses applicability of group keying to RSVP encryption. 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, 13-Nov-07, 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. IPv6 Operations (v6ops) ----------------------- "IPv6 Deployment Scenarios in 802.16 Networks", Myung-Ki Shin, 28-Jan-08, This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document we will discuss main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies. "IPv6 Unicast Address Assignment Considerations", Gunter Van de Velde, Chip Popoviciu, Tim Chown, Olaf Bonness, Christian Hahn, 7-Nov-07, 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. "Requirements for address selection mechanisms", Arifumi Matsumoto, 11-Mar-08, There are some problematic cases when using default address selection mechanism which RFC 3484 defines. This document describes additional requirements co-working with RFC3484 to solve the problems. "Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules", Arifumi Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, Ken-ichi Kanayama, 25-Feb-08, One physical link can carry multiple subnets. Moreover, we can use multiple physical networks at the same time in a host. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. Without an appropriate source/ destination address selection mechanism, the host will experience some trouble in communication. RFC 3484 defines default source and destination address selection algorithms, but the multi-prefix environment considered here needs additional rules beyond those of the default operation. This document describes the possible problems that end hosts could encounter in an environment with multiple subnets. "Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service", James Woodyatt, 13-Feb-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. "Teredo Security Concerns", James Hoagland, Suresh Krishnan, 25-Feb-08, Additional security concerns with Teredo are documented, beyond what is in RFC 4380. This is based on an independent analysis of Teredo's security implications. The primary intent of this document is to raise the awareness regarding the security issues in Teredo as deployed today. vCard and CardDAV (vcarddav) ---------------------------- "vCard Format Specification", Pete Resnick, Simon Perreault, 9-Apr-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.). Virtual Router Redundancy Protocol (vrrp) ----------------------------------------- "Definitions of Managed Objects for the VRRP over IPv4 and IPv6", Kalyan Tata, 15-Dec-06, This specification defines a Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol for both IPv4 and IPv6 as defined in RFC 3768 and RFC xxxx ( RFC-editor, this is currently draft-ietf-vrrp-ipv6-spec-07.txt). This memo obsoletes RFC 2787. "Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6", Stephen Nadas, 19-Mar-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, 15-Nov-07, 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) ------------------------------- "A Framework for Centralized Conferencing", Mary Barnes, Chris Boulton, Orit Levin, 9-Nov-07, This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISUP, to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. "Conference Information Data Model for Centralized Conferencing (XCON)", Oscar Novo, Gonzalo Camarillo, David Morgan, Roni Even, 28-Mar-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, 15-Feb-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.