Current Internet-Drafts This summary sheet provides a short synopsis of each Internet-Draft available within the "internet-drafts" directory at the shadow sites directory. These drafts are listed alphabetically by working group acronym and start date. IP over IEEE 802.16 Networks (16ng) ----------------------------------- "Transmission of IP over Ethernet over IEEE 802.16 Networks", HongSeok Jeon, 18-Apr-08, This document describes the transmission of IPv4 over Ethernet as well as IPv6 over Ethernet in an access network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections which the IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 MAC functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. "Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer", Syam Madanapalli, Soohong Daniel Park, Samita Chakrabarti, 13-Jul-08, IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service specific convergence sublayers for transmitting upper layer protocols. The packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as Internet Protocol (IP), IEEE 802.3 (Ethernet) and IEEE 802.1Q (VLAN). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 MAC. This document specifies the frame format, the Maximum Transmission Unit (MTU) and address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16. IPv6 over Low power WPAN (6lowpan) ---------------------------------- "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", Jonathan Hui, Pascal Thubert, 8-Oct-08, This document specifies an IPv6 header compression format for IPv6 packet delivery in 6LoWPAN networks. The compression format relies on shared context to allow compression of arbitrary prefixes. This document specifies compression of multicast addresses and a framework for compressing next headers. This framework specifies UDP compression and is prepared for additional transports. IPv6 Maintenance (6man) ----------------------- "Solution approaches for address-selection problems", Arifumi Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, Ken-ichi Kanayama, 18-Jun-08, In response to address selection problem statement and requirement documents, this document describes approaches to solutions and evaluates proposed solution mechanisms in line with requirements. It also examines the applicability of each solution mechanism from the viewpoint of practical application. Matsumoto, et al. Expires August 2, 2008 [page 1] "Reserved IPv6 Interface Identifiers", Suresh Krishnan, 14-Jul-08, Interface Identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. An IPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one. "IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes", Hemant Singh, Wes Beebee, Erik Nordmark, 6-Oct-08, IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference; that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also invalidates (partially due to security concerns) a part of the definition of on-link from [RFC4861]. "Handling of overlapping IPv6 fragments", Suresh Krishnan, 22-Sep-08, The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. ADSL MIB (adslmib) ------------------ "Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)", Moti Morgenstern, Scott Baillie, Umberto Bonollo, 8-Jul-08, This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing ADSL, ADSL2, and ADSL2+ interfaces. "xDSL multi-pair bonding (G.Bond) MIB", Edward Beili, Moti Morgenstern, Narendranath Nair, 1-Sep-08, This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. Access Node Control Protocol (ancp) ----------------------------------- "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", Sven Ooghe, Norbert Voigt, Michel Platnic, Thomas Haag, Sanjay Wadhwa, 9-May-08, The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing OSS systems. "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", Hassnaa Moustafa, Hannes Tschofenig, Stefaan De Cnodder, 7-Oct-08, The Access Node Control Protocol (ANCP) aims to communicate QoS- related, service-related and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage and control access equipments including the ability for the access nodes to report information to the NAS. The present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security aiming to decide which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. "Protocol for Access Node Control Mechanism in Broadband Networks", Jerome Moisand, Swami Subramanian, Thomas Haag, Norbert Voigt, Sanjay Wadhwa, 14-Jul-08, This document describes proposed extensions to the GSMPv3 protocol to allow its use in a broadband environment, as a control plane between Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). These proposed extensions are required to realize a protocol for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK]. The resulting protocol with the proposed extensions to GSMPv3 [RFC3292] is referred to as "Access Node Control Protocol" (ANCP). This document currently focuses on specific use cases of access node control mechanism for topology discovery, line configuration, and OAM as described in ANCP framework document [ANCP-FRAMEWORK]. It is intended to be augmented by additional protocol specification for future use cases considered in scope by the ANCP charter. ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases in detail. Illustrative text for the use-cases is included here to help the protocol implementer understand the greater context of ANCP protocol interactions. "Access Node Control Protocol (ANCP) MIB module for Access Nodes", Stefaan De Cnodder, Moti Morgenstern, 24-Jun-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- "Mobile Ad hoc Network Architecture", Ian Chakeres, Joseph Macker, Thomas Clausen, 7-Nov-07, This document discusses Mobile Ad hoc NETworks (MANETs). It presents the initial motivation for MANET and describes unaccustomed characteristics and challenges. It also defines a MANET, other MANET entities, and MANET architectural concepts. Audio/Video Transport (avt) --------------------------- "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Joerg Ott, 7-Jan-08, This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. Ott et al. Internet Draft - Expires July 2008 [page 1] RTCP with Unicast Feedback "RTP Payload Format for JPEG 2000 Video Streams", Satoshi Futemma, 30-Jun-08, 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, 4-Sep-08, This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. "Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery", Andrew Leung, 30-Jun-08, This memo describes extended uses for payload header in "RTP Payload Format for JPEG 2000 Video Streams" as specified in RFC XXXY. For better support of JPEG 2000 features such as scalability and main header recovery. 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. -- RFC-Editor Note: The authors ask the RFC Editors to replace all instances of RFC XXXY with the RFC number assigned when draft-ietf-avt-rtp-jpeg2000-20 [JP2RTP] is published as an RFC. At that time, please remove the note. "Associating Time-codes with RTP streams", David Singer, 24-Jun-08, This document describes a mechanism for associating time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams, in a way that is independent of the RTP payload format of the media stream itself. "RTP Payload Format for ITU-T Recommendation G.722.1", Patrick Luthi, Roni Even, 22-Aug-08, International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. The document also describes the syntax and semantics of the SDP parameters needed to support G.722.1 audio codec. "RTP Payload Format for the Speex Codec", Greg Herlein, Jean-Marc Valin, Alfred Heggestad, Aymeric Moizard, 16-Feb-08, Speex is an open-source voice codec suitable for use in Voice over IP (VoIP) type applications. This document describes the payload format for Speex generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP).Editors Note All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published. "How to Write an RTP Payload Format", Magnus Westerlund, 11-Sep-08, This document contains information on how to best write an RTP payload format. Reading tips, design practices, and practical tips on how to quickly and with good results produce an RTP payload format specification. A template is also included with instructions that can be used when writing an RTP payload format. "Transmission Time offsets in RTP streams", David Singer, HariKishan Desineni, 11-Mar-08, This document describes a method to inform RTP clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. "Multiplexing RTP Data and Control Packets on a Single Port", Colin Perkins, Magnus Westerlund, 6-Aug-07, This memo discusses issues that arise when multiplexing RTP data packets and RTP control protocol (RTCP) packets on a single UDP port. It updates RFC 3550 to describe when such multiplexing is, and is not, appropriate, and explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. "RTP Payload Format for SVC Video", Stephan Wenger, Ye-Kui Wang, Thomas Schierl, Alex Eleftheriadis, 26-Sep-08, This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in_Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. For single-session transmission the packetization modes of RFC 3984 are used. For multi-session transmission four different modes are defined in this memo. The modes differ depending on whether the SVC data are allowed to be interleaved, i.e., to be transmitted in an order different than the intended decoding order, and they also differ in the mechanisms provided in order to recover the correct decoding order of the NAL units across the multiple RTP sessions. Specifically, decoding order recovery is performed using either timestamp alignment or Cross-Session Decoding Order Numbers (CS- DON), although in one of the modes both schemes are used in order to allow receivers to use their preferred method. The multi-session transmission modes use the packetization modes defined in RFC 3984 as each individual session still uses a packetization mode defined in RFC 3984. The packetization modes defined in RFC 3984 are slightly extended such that the three new NAL unit types defined in this memo can be included in the RTP packet streams. The payload format defines a new media subtype name "H264-SVC", but is still backwards compatible to RFC 3984 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 3984. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. Table of Contents Status of this Memo...............................................1 Copyright Notice..................................................1 Abstract..........................................................2 "RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, Intellectual Property, 6-Aug-08, This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. "RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec", Yusuke Hiwasaki, Hitoshi Ohmuro, 25-Feb-08, This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. "Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows.", Xavier Marjou, Aurelien Sollaud, 2-Oct-08, This document lists the different mechanisms that enable applications using Real-time Transport Protocol (RTP) to maintain their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", David McGrew, Eric Rescorla, 11-Sep-08, This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for secure RTP (SRTP) and secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. "Forward-shifted RTP Redundancy Payload Support", Qiaobing Xie, 7-Oct-08, This document defines a simple enhancement to RFC 2198 to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). "The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP)", Intellectual Property, 29-Sep-08, This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). "Support for Reduced-Size RTCP, Opportunities and Consequences", Ingemar Johansson, Magnus Westerlund, 4-Sep-08, This memo discusses benefits and issues that arise when allowing RTCP packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC3550 are removed or changed. Based on that analysis this memo defines certain changes to the rules to allow feedback messages to be sent as reduced-size RTCP packets under certain conditions when using the RTP AVPF profile (RFC 4585). This document updates [RFC3550], [RFC3711] and [RFC4585]. "RTP Payload Format for H.264 RCDO Video", Tom Kristensen, 22-May-08, This memo describes an RTP Payload format for the Reduced-Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RTP Payload format is based on the description in RFC 3984. "G.729.1 RTP Payload Format update: DTX support", Aurelien Sollaud, 26-Sep-08, This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) Recommendation G.729.1 audio codec. It adds Discontinuous Transmission (DTX) support to the RFC 4749 specification, in a backward-compatible way. An updated media type registration is included for this payload format. "RTP Payload Format for ITU-T Recommendation G.711.1", Aurelien Sollaud, 28-Apr-08, This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.711.1 audio codec. Two media type registrations are also included. "Guidelines for Extending the RTP Control Protocol (RTCP)", Joerg Ott, Colin Perkins, 7-Jul-08, The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptivity and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient. "RTP Payload Format for Elementary Streams with MPEG Surround multi- channel audio", Frans Bont, Stefan Doehla, Malte Schmidt, Ralph Sperschneider, 7-Jul-08, This memo describes extensions for the RTP payload format defined in RFC3640 for the transport of MPEG Surround multi-channel audio. Additional MIME Type parameters are defined to signal backwards compatible transmission inside an MPEG-4 audio elementary stream. In addition a layered transmission scheme without using the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data. "RTP Payload format for G.719", Magnus Westerlund, Ingemar Johansson, 8-Oct-08, This document specifies the payload format for packetization of the G.719 full-band codec encoded audio signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving. "Post-Repair Loss RLE Report Block Type for RTCP XR", Ali Begen, Dong Hsu, Michael Lague, 6-Aug-08, This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XR). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys the information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE Report, carries the information regarding the remaining lost packets after all error-repair techniques are applied. By comparing the RTP packet receipts/losses before and after the error repair is completed, one can determine the effectiveness of the error-repair techniques in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE Report in the Session Description Protocol (SDP). "Why RTP Does Not Mandate a Single Security Mechanism", Colin Perkins, Magnus Westerlund, 29-Jul-08, This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP) does not mandate a single media security mechanism. "RTP Payload Format for H.264 Video", Ye-Kui Wang, Roni Even, Tom Kristensen, 6-Oct-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. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Session Traversal Utilities for (NAT) (STUN)", Jonathan Rosenberg, Rohan Mahy, Philip Matthews, Dan Wing, 28-Jul-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, Kaushik Biswas, Bryan Ford, Senthil Sivakumar, Pyda Srisuresh, 6-Sep-08, 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, 29-Sep-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. "NAT Behavioral Requirements for ICMP protocol", Pyda Srisuresh, Bryan Ford, Senthil Sivakumar, Saikat Guha, 30-Sep-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, 29-Jul-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. "Test vectors for STUN", Remi Denis-Courmont, 27-Jul-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. "Network Address Translation (NAT) Behavioral Requirements for DCCP", Remi Denis-Courmont, 4-Oct-08, This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). Those allow DCCP applications, such as streaming applications to operate consistently. These requirements are very similar to the TCP requirements for NATs already published by the IETF Behavior Engineering for Hindrance Avoidance (BEHAVE) working group. Developing NATs that meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD Management Information Base", Thomas Nadeau, Zafar Ali, Nobo Akiya, 4-Aug-08, This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. "BFD For MPLS LSPs", Rahul Aggarwal, Kireeti Kompella, Thomas Nadeau, George Swallow, 20-Jun-08, One desirable application of Bi-directional Forwarding Detection (BFD) is to detect a Multi Protocol Label Switched (MPLS) Label Switched Path (LSP) data plane failure. LSP-Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However the control plane processing required for BFD control packets is relatively smaller than the processing required for LSP-Ping messages. A combination of LSP-Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP-Ping for this application. It also describes procedures for using BFD in this environment. "Bidirectional Forwarding Detection", Dave Katz, David Ward, 24-Mar-08, This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. "BFD for Multihop Paths", Dave Katz, David Ward, 16-Jan-08, This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. "BFD for IPv4 and IPv6 (Single Hop)", Dave Katz, David Ward, 24-Mar-08, This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. Comments on this draft should be directed to rtg-bfd@ietf.org. "Generic Application of BFD", Dave Katz, David Ward, 16-Jan-08, This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. Comments on this draft should be directed to rtg-bfd@ietf.org. Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- "An Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP)", John Elwell, 24-May-08, This discusses problems associated with automatic call handling (ACH) when using the Session Initiation Protocol (SIP). This work is being discussed on the bliss@ietf.org mailing list. "Call Completion for Session Initiation Protocol (SIP)", Dale Worley, Martin Huelsemann, Denis Alexeitsev, 20-Jun-08, The features "call completion on busy subscriber" and "call completion on no reply" allow the calling party of a failed call to be notified when the called party becomes available to receive a call. This document describes an architecture for implementing these features in the Session Initiation Protocol: "Call completion" implementations at the caller's and callee's endpoints cooperate to place the caller's request for call completion into a queue at the callee's endpoint, and, when a caller's request is ready to be serviced, re-attempt the original, failed call. "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan, Paul Pepper, Anil Kumar, 25-Sep-08, This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as Shared Appearances (SA) of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in 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. Benchmarking Methodology (bmwg) ------------------------------- "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 "MPLS Forwarding Benchmarking Methodology", Aamer Akhter, Rajiv Asati, 15-Sep-08, The purpose of this draft is to describe a methodology specific to the benchmarking of MPLS forwarding devices. The scope of this benchmarking will be limited to various types of packet-forwarding and delay measurements. It builds upon the tenets set forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. Better-Than-Nothing Security (btns) ----------------------------------- "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Joseph Touch, David Black, Yu-Shun Wang, 8-Jul-08, The Internet network security protocol suite, IPsec, requires authentication, usually of network layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (via KINK). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec. This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing "better than nothing security" (BTNS). The extensions may be used on their own (this use called Stand Alone BTNS, or SAB), or may be used to provide network layer security that can be authenticated by higher layers in the protocol stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable. "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec", Nicolas Williams, Michael Richardson, 5-Aug-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, 14-Apr-08, This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture. Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS), thus connection latching can add a significant measure of protection to BTNS IPsec nodes. Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- "iCalendar Message-Based Interoperability Protocol (iMIP)", Alexey Melnikov, 9-Jun-08, This document, iCalendar Message-Based Interoperability Protocol (iMIP), specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCAL) are composed using constructs from RFC 2822, RFC 2045, RFC 2046, RFC 2047 and RFC 2049. This document is a product of Calendaring and Scheduling Standards Simplification (calsify) working group. More information about the IETF CALSIFY working group activities can be found on the IETF web site at . The issue tracker for the Calsify WG is located at: "iCalendar Transport-Independent Interoperability Protocol (iTIP)", Cyrus Daboo, 14-Jul-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. "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", Bernard Desruisseaux, 6-Feb-08, This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to- dos, journal entries and free/busy information, independent of any particular calendar service or protocol. Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- "CAPWAP Protocol Specification", Michael Montemurro, Dorothy Stanley, Pat Calhoun, 22-Sep-08, This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP working group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. "CAPWAP Protocol Binding for IEEE 802.11", Michael Montemurro, Dorothy Stanley, Pat Calhoun, 26-Sep-08, Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. "CAPWAP Threat Analysis for IEEE 802.11 Deployments", Scott Kelly, Charles Clancy, 10-Sep-08, Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP) which serves as a stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning for Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP, and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. "CAPWAP Access Controller DHCP Option", Pat Calhoun, 14-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. "CAPWAP Protocol Base MIB", Yang Shi, David Perkins, Chris Elliott, Yong Zhang, 10-Oct-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. "CAPWAP Protocol Binding MIB for IEEE 802.11", Yang Shi, David Perkins, Chris Elliott, Yong Zhang, 10-Oct-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol for IEEE 802.11 wireless binding. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Ethernet Traffic Parameters", Dimitri Papadimitriou, Intellectual Property, 12-Jul-08, This document describes the Metro Ethernet Forum (MEF) - specific Ethernet Traffic Parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", Zafar Ali, JP Vasseur, Anca Zamfir, 3-Jul-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, 8-Jul-08, This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Thomas Nadeau, 4-Aug-08, This memo defines the Management Information Base (MIB) objects in order to manage traffic engineering database (TED) information with extension in support of Multi-Protocol Label Switching (MPLS) with traffic engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. "draft-ietf-ccamp-pc-and-sc-reqs-06.txt", Diego Caviglia, Dino Bramanti, Dan Li, Dave McDysan, 15-Sep-08, From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. "OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering", Mach Chen, Renhai Zhang, 27-Jul-08, This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. "Description of the RSVP-TE Graceful Restart Procedures", Dan Li, 19-May-08, The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) network for state recovery of control channel or nodal faults. "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", Dimitri Papadimitriou, Martin Vigoureux, Kohei Shiomoto, Deborah Brungard, Jean-Louis Roux, Eiji Oki, Ichiro Inoue, Emmanuel Dotaro, Gert Grammel, 14-Jul-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, 4-Sep-08, This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter- AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. "GMPLS Ethernet Label Switching Architecture and Framework", Don Fedyk, Lou Berger, Loa Andersson, 13-Jul-08, There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as SONET/SDH TDM and ATM. This document defines an architecture and framework for a GMPLS based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed and this document provides a framework for these extensions.Contents "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", Adrian Farrel, Dimitri Papadimitriou, JP Vasseur, Arthi Ayyangar, 27-May-08, Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", Lou Berger, Attila Takacs, Diego Caviglia, Don Fedyk, Julien Meuric, 29-Apr-08, This document defines a method for the support of GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original RSVP model for the transport of traffic related parameters. The procedures described in this document are experimental. "Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks", Weiqiang Sun, Guoying Zhang, Jianhua Gao, Guowu Xie, Rajiv Papneja, Bin Gu, Xueqing Wei, 24-Jun-08, Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for Dynamicly provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the Dynamic LSP setup/release performance. These metrics can depict the features of GMPLS networks in LSP dynamic provisioning. They can also be used in operational networks for carriers to monitor the control plane performance in realtime. "RSVP Extensions for Path Key Support", Richard Bradford, JP Vasseur, Adrian Farrel, 14-May-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 within 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 how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Object (RROs) so facilitate confiedntiality in the signaling of inter-domain TE LSPs. "RSVP-TE Signaling Extension For The Conversion Between Permanent Connections And Soft Permanent Connections In A GMPLS Enabled Transport Network.", Diego Caviglia, Dino Bramanti, Dan Li, Snigdho Bardalai, 15-Jul-08, We would like to dedicate this work to our friend and colleague Dino Bramanti, who passed away at the early age of 38. Dino has been involved in this work since its beginning. In a transport network scenario, where Data Plane connections controlled either by GMPLS Control Plane (Soft Permanent Connections - SPC) or by Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a requirement. See draft "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. This memo provides a minor extension to RSVP-TE [RFC2205],[RFC3471],[RFC3473],[RFC4872] signaling protocol, within GMPLS architecture, to enable such connection ownership transfer and describes the proposed procedures. Failure conductions and subsequent roll back are also illustrated taking into account that an handover failure must not impact the already established data plane connections. "GMPLS control of Ethernet PBB-TE", Don Fedyk, David Allan, Himanshu Shah, Nabil Bitar, Attila Takacs, Diego Caviglia, Alan McGuire, Nurit Sprecher, Lou Berger, 13-Jul-08, This specification is complementary to the GMPLS controlled Ethernet architecture document [ARCH] and describes the technology specific aspects of GMPLS control for Provider Backbone Bridging Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point to point (P2P) and point to multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching", Lou Berger, Don Fedyk, 8-Aug-08, This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line service and Ethernet virtual private line service. Support for MEF and ITU defined parameters are also covered. Some of the extensions defined in this document are generic in nature and not specific to Ethernet. "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)", Lou Berger, Don Fedyk, 8-Aug-08, This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required to implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)", Greg Bernstein, Young Lee, Wataru Imajuku, 13-May-08, This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul. "Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers", Tomohiro Otani, Hongxiang Guo, Keiji Miyazaki, Diego Caviglia, 14-Jul-08, Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. However, RFC 3471 has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with ITU-T G.694. Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. "Service Provider Requirements for Ethernet control with GMPLS", Wataru Imajuku, Yoshiaki Sone, Muneyoshi Suzuki, Kazuhiro Matsuda, Nabil Bitar, 11-Jun-08, Generalized Multi-Protocol Label Switching (GMPLS) is applicable to Ethernet switches supporting Provider Backbone Bridge Traffic Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label switch network not only automates creation of Ethernet Label Switched Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery Mechanisms such as protection and restoration of an Eth-LSP. This document describes the requirements for the set of solutions of GMPLS controlled Ethernet label switch networks. "Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions", Lou Berger, Don Fedyk, 8-Aug-08, This document describes two technology independent extensions to Generalized Multi-Protocol Label Switching. The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of an LSP. "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", Greg Bernstein, Young Lee, Dan Li, Wataru Imajuku, 29-Aug-08, This document provides an information model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of information described in this model is to facilitate constrained lightpath computation in WSONs. In particular in cases where there are no or a limited number of wavelength converters available in the WSON. This model currently does not include optical impairments. Cga & Send maIntenance (csi) ---------------------------- "SeND Hash Threat Analysis", Ana Kukec, Suresh Krishnan, Sheng Jiang, 10-Sep-08, This document analysis the use of hashes in SeND, possible threats and the impact of recent attacks on hash functions used by SeND. Current SeND specification [rfc3971] uses SHA-1 [sha-1] hash algorithm and PKIX certificates [rfc3280] and does not provide support for the hash algorithm agility. The purpose of the document is to provide analysis of possible hash threats and to decide how to encode the hash agility support in SeND. Datagram Congestion Control Protocol (dccp) ------------------------------------------- "Faster Restart for TCP Friendly Rate Control (TFRC)", Eddie Kohler, Sally Floyd, Arjuna Sathiaseelan, Intellectual Property, 14-Jul-08, TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. This document introduces Faster Restart, an optional mechanism for safely improving the behavior of interactive flows that use TFRC. Faster Restart is proposed for use with TFRC and with TFRC-SP, the Small Packet variant of TFRC. We present Faster Restart in general terms as a congestion control mechanism, and further discuss Faster Restart for Datagram Congestion Control Protocol (DCCP) Congestion Control IDs 3 and 4. "RTP and the Datagram Congestion Control Protocol (DCCP)", Colin Perkins, 22-Jun-07, The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a newly defined transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real-time applications can make use of the services provided by DCCP. "The DCCP Service Code", Gorry Fairhurst, 29-Sep-08, This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g. network address translators and firewalls). This document updates the specification provided in RFC 4340. "DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal", Gorry Fairhurst, 8-Oct-08, This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g. a DCCP server behind a firewall, or a Network Address Port Translator), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. "Quick-Start for Datagram Congestion Control Protocol (DCCP)", Gorry Fairhurst, 5-Sep-08, This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and on-line games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID-2 and CCID-3. Quick-Start enables a DCCP sender to cooperate with any Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start and, at times, in the middle of a DCCP connection (e.g., after an idle or application-limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. Dynamic Host Configuration (dhc) -------------------------------- "Virtual Subnet Selection Options for DHCPv4 and DHCPv6", Kim Kinnear, Richard Johnson, Mark Stapp, Jay Kumarasamy, 8-Jul-08, This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and relay-agent-information sub-option, this memo documents existing usage as per RFC 3942 [RFC3942]. "Subnet Allocation Option", Richard Johnson, 8-Jul-08, This document defines a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. "Rebind Capability in DHCPv6 Reconfigure Messages", D Evans, Ralph Droms, 8-Sep-08, 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. "Guidelines for Creating New DHCP Options", David Hankins, 8-Sep-08, This document seeks to provide guidance to prospective DHCP Option authors, to help them in producing option formats that are easily adoptable. "Container Option for Server Configuration", Ralph Droms, 8-Sep-08, In some DHCP service deployments, it is desirable for a DHCP server in one administrative domain to pass configuration options to a DHCP server in a different administrative domain. This DHCP option carries a set of DHCP options that can be used by another DHCP server. "Layer 2 Relay Agent Information", Bharat Joshi, Pavan Kurapati, 1-Oct-08, In some networks, DHCP servers rely on Relay Agent Information option appended by Relay Agents for IP address and other parameter assignment policies. This works fine when end hosts are directly connected to Relay Agents. In some network configurations, one or more Layer 2 devices may reside between DHCP clients and Relay agent. In these network scenarios, it is difficult to use the Relay Agent Information option for IP address and other parameter assignment policies effectively. So there is a need for the device that is closest to the end hosts to append Relay Agent Information option in DHCP messages. These devices are typically known as Layer 2 Relay Agents. This document aims to describe the network scenarios where Layer 2 Relay Agent is in use and also how it handles DHCP messages. "DHCPv6 Bulk Leasequery", Mark Stapp, 12-Jun-08, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. "Extensions to Layer 2 Relay Agent", Bharat Joshi, Pavan Kurapati, Mukund Kamath, Stefaan De Cnodder, 14-Jun-08, As per industry trends, Access Networks have been migrating from traditional ATM based networks to Ethernet networks. In Ethernet based access networks, Access Concentrators are typically configured to act as a transparent bridge in Layer 2 mode. These Access Concentrators also act as Layer 2 relay agents. Layer 2 Relay Agent functionality does not provide means to avoid flooding of DHCP messages and also needs to be extended to support DHCP LeaseQuery This draft discusses these issues and provides solutions for the same. "The DHCPv4 Relay Agent Identifier Suboption", Mark Stapp, 30-Sep-08, This memo defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device. The value may be administratively-configured or may be generated by the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. "DHCPv6 option for network boot", Thomas Huth, Jens Freimann, 19-Aug-08, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes a new option for DHCPv6 to convey information, required for network booting, to the nodes. Diameter Maintenance and Extensions (dime) ------------------------------------------ "The Diameter API", Pat Calhoun, David Frascone, 28-Jul-08, The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes an API for the Diameter protocol. The API is defined for the C language. The intent of the API is to foster source code portability across multiple programming platforms. "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", Jouni Korhonen, Hannes Tschofenig, Julien Bournelle, Gerardo Giaretta, Madjid Nakhjiri, 23-Sep-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, 5-Sep-08, A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. "Diameter Base Protocol", Victor Fajardo, Jari Arkko, John Loughney, Glen Zorn, 8-Sep-08, The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. "Diameter Quality of Service Application", Dong Sun, Peter McCann, Hannes Tschofenig, Tina Tsou, Avri Doria, Glen Zorn, 13-Jul-08, This document describes the framework, messages and procedures for the Diameter Quality of Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation -- Pull and Push -- are defined. "Diameter Applications Design Guidelines", Victor Fajardo, Tolga Asveren, Hannes Tschofenig, Glenn McGregor, John Loughney, 13-Jul-08, The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol that further explains and clarifies these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. "Quality of Service Parameters for Usage with the AAA Framework", Jouni Korhonen, Hannes Tschofenig, 26-May-08, This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. "Quality of Service Attributes for Diameter", Jouni Korhonen, Hannes Tschofenig, Mayutan Arumaithurai, Mark Jones, Avi Lior, 26-Jun-08, This document extends the IPFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing and future Diameter applications where permitted by the command ABNF. Domain Keys Identified Mail (dkim) ---------------------------------- "DomainKeys Identified Mail (DKIM) Service Overview", Tony Hansen, Dave Crocker, Phillip Hallam-Baker, 11-Jul-08, This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public- key cryptography, using the domain name service as its key server technology [RFC4871]. This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing. "DKIM Author Domain Signing Practices (ADSP)", agent Local-part, Eric Allman, Jim Fenton, Mark Delany, John Levine, 19-Sep-08, DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail, and how other hosts can access that record. Detecting Network Attachment (dna) ---------------------------------- "Design document for Detecting Network Attachment in IPv6 Networks (DNAv6 Design)", Sathya Narayanan, James Kempf, Erik Nordmark, Brett Pentland, JinHyeock Choi, Greg Daley, Nicolas Montavont, 11-Jul-08, Efficient detection of network attachment in IPv6 needs the following three components: a method for hosts to detect link change in the presence of unmodified (non-DNAv6) routers, a method for the host to query routers on the link to identify the link (Link Identification) and a method for the routers on the link to consistently respond to such a query with minimal delay (Fast RA). Solving the link identification based strictly on RFC 2461 is difficult because of the flexibility offered to routers in terms of prefixes advertised in a router advertisement (RA) message. Similarly, the random delay in responding to router solicitation messages imposed by RFC 2461 makes it difficult to receive an RA quickly. In this memo, a mechanism that was developed for detection of network attachement is documented for future reference. This memo is an informational document and thus does not define a new standard. The mechanism proposed in this informational RFC requires the hosts to monitor all the prefixes advertised on the link and use it for link identification in the presence of non-DNAv6 routers is presented. A more efficient link- identification mechanism requiring the DNAv6 routers to monitor the link for advertised prefixes to assist the hosts in link identification combined with a fast router advertisement mechanism that selects the order of response for the router deterministically is also presented. "Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery", Greg Daley, Erik Nordmark, 13-Jul-08, The proposed IPv6 Duplicate Address Detection (DAD) Optimization "Optimistic DAD" defines a set of recoverable procedures which allow a node to make use of an address before DAD completes. Essentially, Optimistic DAD forbids usage of certain Neighbour Discovery options which could pollute active neighbour cache entries, while an address is tentative. This document defines a new option and procedures to replace cache polluting options, in a way which is useful to tentative nodes. These procedures are designed to be to backward compatible with existing devices which support IPv6 Neighbour Discovery. "Simple procedures for Detecting Network Attachment in IPv6", Suresh Krishnan, Greg Daley, 3-Oct-08, Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for detecting network attachment in IPv6 hosts, and procedures for routers to support such services. DNS Extensions (dnsext) ----------------------- "DNS Zone Transfer Protocol (AXFR)", Edward Lewis, 14-Jul-08, The Domain Name System standard mechanisms for maintaining coherent servers for a zone consist of three elements. One mechanism is the Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The definition of AXFR, has proven insufficient in detail, forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of the AXFR, new in the sense that is it recording an accurate definition of an interoperable AXFR mechanism. "Evaluating DNSSEC Transition Mechanisms", Roy Arends, Peter Koch, Jakob Schlyter, 14-Jul-08, This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. It is a snapshot of the DNSEXT working group discussion of June 2004. "Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, David Blacka, 14-Jul-08, This document is a collection of minor technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as an interim repository of DNSSECbis errata. "Domain Name System (DNS) IANA Considerations", Donald Eastlake 3rd, 14-Jul-08, Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", Jelte Jansen, 29-Jul-08, This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). "Update to DNAME Redirection in the DNS", Scott Rose, Wouter Wijngaards, 16-Jul-08, The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision. "Measures for making DNS more resilient against forged answers", Bert Hubert, Remco Mook, 14-Aug-08, The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. By describing certain behaviour that has previously not been standardised, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 1034. "Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records", Francis Dupont, 30-Jun-08, The main goal of this document is to deprecate the use of HMAC-MD5 as an algorithm for the TSIG (secret key transaction authentication) resource record in the DNS (domain name system). Domain Name System Operations (dnsop) ------------------------------------- "DNS Referral Response Size Issues", Paul Vixie, Akira Kato, 14-Jul-08, With a mandated default minimum maximum UDP message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit, and suggests ways to optimize the use of this limited space. Guidance is offered to DNS server implementors and to DNS zone operators. "Preventing Use of Recursive Nameservers in Reflector Attacks", Joao Luis Damas, Frederico Neves, 1-Sep-08, 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, 10-Jul-08, Experience has shown that there are a number of DNS zones all iterative resolvers and recursive nameservers should, unless configured otherwise, automatically serve. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well known zones with similar characteristics. "Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt Larson, 14-Jul-08, This document describes the initial queries a DNS resolver is supposed to emit to initialize its cache with a current NS RRSet for the root zone as well as the necessary address information. "DNSSEC Trust Anchor Configuration and Maintenance", Matt Larson, Olafur Gudmundsson, 14-Jul-08, This document recommends a preferred format for specifying trust anchors in DNSSEC validating security-aware resolvers and describes how such a resolver should initialize trust anchors for use. This document also describes different mechanisms for keeping trust anchors up to date over time. "Requirements for Management of Name Servers for the DNS", Wesley Hardaker, 3-Sep-08, Management of name servers for the Domain Name Service (DNS) has traditionally been done using vendor-specific monitoring, configuration and control methods. Although some service monitoring platforms can test the functionality of the DNS itself there is not a interoperable way to manage (monitor, control and configure) the internal aspects of a name server itself. This document discusses the requirements of a management system for DNS name servers. A management solution that is designed to manage the DNS can use this document as a shopping list of needed features. Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- "Consolidated Provisioning Problem Statement", David Schwartz, Rohan Mahy, Alan Duric, Edward Lewis, 7-Jul-08, This document describes the type of data provisioned among Voice Service Providers and underscores the need for clearly defined structures and interfaces to facilitate this provisioning. This work is in support of the service provider peering as defined by the SPEERMINT WG. Email Address Internationalization (eai) ---------------------------------------- "Downgrading mechanism for Email Address Internationalization", Kazunori Fujiwara, Yoshiro Yoneya, 16-Sep-08, Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized Email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. "IMAP Support for UTF-8", Pete Resnick, Chris Newman, 24-Apr-08, This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. This is an early draft and intended as a framework for discussion. Please do not deploy implementations of this draft. "POP3 Support for UTF-8", Chris Newman, Randall Gellens, 13-Jul-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. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Location-to-URL Mapping Architecture and Framework", Henning Schulzrinne, 29-Sep-07, This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs, using the Location-to- Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. "Best Current Practice for Communications Services in support of Emergency Calling", Brian Rosen, James Polk, 10-Jul-08, The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. "Framework for Emergency Calling using Internet Multimedia", Brian Rosen, Henning Schulzrinne, James Polk, Andrew Newton, 10-Jul-08, The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. "Location Hiding: Problem Statement and Requirements", Henning Schulzrinne, Laura Liess, Hannes Tschofenig, Barbara Stark, Andres Kuett, 12-Oct-08, The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to end points or VoIP service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). For determining the PSAP Uniform Resource Identifier (URI) the usage of the Location-to- Service Translation (LoST) Protocol is envisioned. This document explores the architectural impact for the IETF emergency services architecture for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document provides a problem statement and lists requirements. "Specifying Holes in LoST Service Boundaries", James Winterbottom, Martin Thomson, 12-Oct-08, This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a LoST server, is described. "Synchronizing Location-to-Service Translation (LoST) Servers", Henning Schulzrinne, 7-Jul-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. EAP Method Update (emu) ----------------------- "EAP Generalized Pre-Shared Key (EAP-GPSK) Method", Charles Clancy, Hannes Tschofenig, 1-Oct-08, 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. "Requirements for an Tunnel Based EAP Method", Katrin Hoeper, Stephen Hanna, Hao Zhou, Joseph Salowey, 25-Jun-08, This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. Telephone Number Mapping (enum) ------------------------------- "ENUM Implementation Issues and Experiences", Lawrence Conroy, Kazunori Fujiwara, 6-Oct-08, This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. It does not revise the standards, but it is intended to provide technical input to future revisions of those documents. "IANA Registration for IAX Enumservice", Ed Guy, 17-Jun-08, This document registers the IAX Enumservice using the URI scheme 'iax:' as per the IANA registration process defined in the ENUM specification RFC3761. "IANA Registration of Enumservices: Guide, Template and IANA Considerations", Hoeneisen Bernie, Alexander Mayrhofer, Jason Livingood, 1-Sep-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'", Richard Shockey, 29-Sep-08, This document registers the Enumservice 'pstndata' and subtype 'cnam' using the URI scheme 'pstndata:' as per the IANA registration process defined in the ENUM specification, RFC 3761 and registers a new URI type 'pstndata:'. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). The pstndata URI is created to facilitate this transfer, however this URI may be used to transport other PSTN data in the future. "Combined User and Infrastructure ENUM in the e164.arpa tree", Michael Haberler, Otmar Lendl, Richard Stastny, 22-Oct-07, This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after approval and implementation of the long-term solution. "ENUM Requirement for EDNS0 Support", Jim Reid, Lawrence Conroy, 6-Sep-06, Support for EDNS0 (Extension Mechanisms for DNS) is mandated in this document for DNS entities querying for or serving NAPTR records. In general those entities will be supporting ENUM resolution. This requirement is needed because DNS responses to ENUM-related queries generally return large RRSets. Without EDNS0 support these lookups would result in truncated responses and repeated queries over TCP transport. That has a severe impact on DNS server load and on the latency of those queries. This document adds an operational requirement to use of the protocol standardised in RFC 3761. "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", Scott Bradner, Lawrence Conroy, Kazunori Fujiwara, 31-Mar-08, This document discusses the use of the Domain Name System (DNS) for the storage of E.164 numbers, and for resolving them into URIs that can be used for (for example) telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. "IANA Registration for Enumservice UNUSED", Richard Stastny, Lawrence Conroy, Jim Reid, 29-Mar-08, This document registers the Enumservice "unused" using the URI scheme "http:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". "IANA Registration of Experimental and Trial Enumservices (X-Enumservices)", Bernie Hoeneisen, 21-May-08, This document specifies a new IANA registry for experimental and trial Enumservices (X-Enumservices), describes corresponding registration procedures, and provides a guideline for creating X-Enumservices and its Registration Documents. "IANA Registrations of Enumservice "sms:smpp" and URI Scheme "smpp"", James Yu, 8-May-08, This document updates RFC 4355 by registering a new enumservice subtype "smpp" under the existing type "sms" using the URI scheme "smpp" as per the IANA registration process defined in RFC 3761 and draft-ietf-enum-enumservices-guide-07 and registers a new URI scheme "smpp" according to the URI registration procedure in RFC 4395. This enumservice subtype indicates that the remote resource identified by the URI can receive short messages using the Short Message Peer-to-Peer Protocol (SMPP). "IANA Registration for an Enumservice Trunkgroup", Richard Shockey, Tom Creighton, 7-Jul-08, This document registers the Enumservice 'trunk' and subtypes 'sip' and 'tel' using the URI schemes 'sip:' and 'tel:' as per the IANA registration process defined in the ENUM specification RFC 3761 [RFC7761]. RFC 4904 [RFC4904] defines a technique for the conveyance of carrying trunking information in SIP [RFC3261] and or TEL [RFC3966] URI's. This Enumservice provides a mechanism for ENUM databases residing in service provider networks a mechanism to query for that data. FEC Framework (fecframe) ------------------------ "Forward Error Correction (FEC) Framework", Mark Watson, 12-Jul-08, This document describes for a framework for using forward error correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying Forward Error Correction to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide Forward Error Correction for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC Scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC Scheme and FEC Schemes can be defined which are not specific to a particular Content Delivery Protocol. "SDP Elements for FEC Framework", Ali Begen, 13-Jul-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. "Signaling Protocol to convey FEC Framework Configuration Information", Rajiv Asati, 6-Jul-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 dynamically communicate the Configuration information between sender(s) and receiver(s). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "RTP Payload Format for 1-D Interleaved Parity FEC", Ali Begen, 29-Aug-08, This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is compatible with and used as a part of the DVB Application-layer FEC Specification. "DVB Application-Layer Hybrid FEC Protection", Ali Begen, Thomas Stockhammer, 29-Aug-08, This document describes the Application-layer Forward Error Correction (FEC) protocol that was developed by the Digital Video Broadcasting (DVB) consortium for the protection of media streams over IP networks. The DVB AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB AL-FEC offers a good protection against both bursty and random packet losses at a cost of decent complexity. The 1-D interleaved parity code and Raptor code have already been specified in separate documents and the current document normatively references these specifications. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Forwarding Element Model", Joel Halpern, Jamal Hadi Salim, 7-Oct-08, This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol [2]. The model represents the capabilities, state and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in the ForCES requirements document, RFC3654 [6]. "ForCES Protocol Specification", Ligang Dong, Avri Doria, Ram Gopal, Robert HAAS, Jamal Hadi Salim, Hormuzd Khosravi, Weiming Wang, 25-Sep-08, This document specifies the Forwarding and Control Element Separation (ForCES) protocol. ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML).Authors The participants in the ForCES Protocol Team, primary co-authors and co-editors, of this protocol specification, are: Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). Special acknowledgement goes to Joel Halpern who has done extensive editing in support of congruence between the model and this protocol specification. Without his participation and persistence, this specification might never have been completed. "ForCES MIB", Robert HAAS, 10-Sep-08, This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it defines managed objects for the Forwarding and Control Element Separation (ForCES) Network Element (NE). "SCTP based TML (Transport Mapping Layer) for ForCES protocol", Jamal Hadi Salim, Kentaro Ogawa, 14-Jul-08, This document defines the SCTP based TML (Transport Mapping Layer) for the ForCES protocol. It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) [RFC2960] and also describes how this TML addresses all the requirements described in [RFC3654] and the ForCES protocol [FE-PROTO] draft. Geographic Location/Privacy (geopriv) ------------------------------------- "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Henning Schulzrinne, Hannes Tschofenig, John Morris, Jorge Cuellar, James Polk, 26-Jun-08, This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access based on the current location of the Target. Furthermore, it offers location- specific transformation elements to reduce the granularity of the returned location information. "Carrying Location Objects in RADIUS and Diameter", Hannes Tschofenig, Farid Adrangi, Mark Jones, Avi Lior, Bernard Aboba, 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, 17-Sep-08, The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented. In these circumstances the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. It further recommends a subset of GML that is mandatory to implement by applications involved in location based routing. "A Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO)", Rohan Mahy, Brian Rosen, 14-Jul-08, This document describes filters which limit asynchronous location notifications to compelling events. The resulting location information is conveyed in existing location formats wrapped in GEOPRIV privacy extensions to the Presence Information Document Format (PIDF-LO) "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", Hannes Tschofenig, Henning Schulzrinne, 29-Jun-08, This document provides a problem statement, lists requirements and captures design aspects for a Geopriv Layer 7 Location Configuration Protocol L7 (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation Protocol (LoST) or to convey location within SIP to other entities. "HTTP Enabled Location Delivery (HELD)", Mary Barnes, James Winterbottom, Martin Thomson, Barbara Stark, 8-Sep-08, A Layer 7 Location Configuration Protocol (L7 LCP) is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of session-layer. This document describes the use of HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer Security (HTTP/TLS) as transports for the protocol. "Requirements for a Location-by-Reference Mechanism", Roger Marshall, 8-Jul-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, 9-Sep-08, A method is described for the discovery of a Location Information Server. The method uses a Dynamic Host Configuration Protocol (DHCP) option. DHCP options are defined for both IPv4 and IPv6 DHCP. A URI-enabled NAPTR (U-NAPTR) method is described for use where the DHCP option is unsuccessful. This document defines a U-NAPTR Application Service for a LIS, with a specific Application Protocol for the HTTP Enabled Location Delivery (HELD) protocol. "Dynamic Host Configuration Protocol (DHCP) Option for a Location Uniform Resource Identifier (URI)", James Polk, 16-Jun-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. "Implications of for SIP Location Conveyance", Ted Hardie, Jon Peterson, John Morris, 3-Jul-08, This document explores an ambiguity in the interpretation of the element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to these ambiguities. Documents standardizing the SIP location conveyance mechanisms will be standards-track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader. Global Routing Operations (grow) -------------------------------- "MRT routing information export format", Larry Blunk, Manish Karir, Craig Labovitz, 14-Jul-08, This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents. Host Identity Protocol (hip) ---------------------------- "Basic HIP Extensions for Traversal of Network Address Translators", Miika Komu, Tom Henderson, Philip Matthews, Hannes Tschofenig, Ari Keraenen, 14-Jul-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 basic 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. "Basic Socket Interface Extensions for Host Identity Protocol (HIP)", Miika Komu, Tom Henderson, 14-Jul-08, This document defines extensions to the current sockets API for Host Identity Protocol (HIP). The extensions focus on the use of public- key based identifiers discovered via DNS resolution, but define also interfaces for manual bindings between HITs and locators. With the extensions, the application can also support more relaxed security models where the communication can be non-HIP based, according to local policies. The extensions in document are experimental and provide basic tools for futher experimentation with policies. Handover Keying (hokey) ----------------------- "EAP Pre-authentication Problem Statement", Yoshihiro Ohba, 9-Sep-08, EAP (Extensible Authentication Protocol) pre-authentication is defined as the use of EAP to pre-establish EAP keying material on a target authenticator prior to arrival of the peer at the access network managed by that authenticator. This draft discusses EAP pre- authentication problems in detail. Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 29-Aug-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, 29-Aug-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, 29-Aug-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, 29-Aug-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, 29-Aug-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, 29-Aug-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, 29-Aug-08, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication. "Security Requirements for HTTP", Paul Hoffman, Alexey Melnikov, 13-Jul-08, Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade- offs of each. "Initial Hypertext Transfer Protocol (HTTP) Method Registrations", Julian Reschke, 29-Aug-08, This document registers those Hypertext Transfer ProtocolHypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs before the IANA HTTP Method Registry was established. Internet Architecture Board (iab) --------------------------------- "Design Choices When Expanding DNS", Patrik Faltstrom, Rob Austein, Peter Koch, 11-Aug-08, This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. Internationalized Domain Names in Applications (Revised) (idnabis) ------------------------------------------------------------------ "The Unicode Codepoints and IDNA", Patrik Faltstrom, 14-Jul-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 IDNA2008. "Internationalized Domain Names for Applications (IDNA): Definitions, Background and Rationale", John Klensin, 7-Oct-08, Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. "Internationalized Domain Names in Applications (IDNA): Protocol", John Klensin, 26-Sep-08, This document supplies the protocol definition for a revised and updated specification for internationalized domain names (IDNs). The rationale for these changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalizing Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. "An updated IDNA criterion for right-to-left scripts", Harald Alvestrand, Cary Karp, 30-Jul-08, The use of right-to-left scripts in internationalized domain names has presented several challenges. This memo discusses some problems with these scripts, and some shortcomings in the 2003 IDNA BIDI criterion. Based on this discussion, it proposes a new BIDI criterion for IDNA labels. Inter-Domain Routing (idr) -------------------------- "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version", Jeffrey Haas, 22-Jun-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol, Version 4. "AS-wide Unique BGP Identifier for BGP-4", Enke Chen, Jenny Yuan, 13-May-08, To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. "Dissemination of flow specification rules", Pedro Roque Marques, Nischal Sheth, Robert Raszuk, Barry Greene, Danny McPherson, 4-Sep-08, This document defines a new BGP NLRI encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more-specific components of the traffic aggregate defined by an IP destination prefix. Additionally it defines two applications of that encoding format. One that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial of service attacks. And a second application to traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the Border Gateway Protocol (BGP), thereby reusing protocol algorithms, operational experience and administrative processes such as inter-provider peering agreements. "Capabilities Advertisement with BGP-4", John Scudder, Ravi Chandra, 22-May-08, This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. "Textual Representation of AS Numbers", Geoff Huston, George Michaelson, 22-Sep-08, A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS Number. This textual representation is to be used by all documents, systems and user interfaces referring to AS numbers. "AS Number Reservation for Documentation Use", Geoff Huston, 3-Oct-08, To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of Autonomous System numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation. IP over Cable Data Network (ipcdn) ---------------------------------- "Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices", Sumanth Channabasappa, Intellectual Property, 17-Aug-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. De Ketelaere/Nechamkin/Channabasappa Expires - February 2009 [page 1] PacketCable/IPCablecom Event management MTA MIB August 2008 IP over DVB (ipdvb) ------------------- "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Prashant Pillai, Michael Noisternig, 23-Aug-08, The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a range of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission. The analysis also describes applicability to the Generic Stream Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB) Project. IP Flow Information Export (ipfix) ---------------------------------- "Architecture for IP Flow Information Export", Ganesh Sadasivan, 10-Sep-06, This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP flows, and for the export of measured IP flow information from an IPFIX device to a collector. "IPFIX Applicability", Tanja Zseby, 3-Jul-07, In this document we describe the applicability of the IP Flow Information Export (IPFIX) protocol for a variety of applications. We show how applications can use IPFIX, describe the relevant information elements (IEs) for those applications and present opportunities and limitations of the protocol. We furthermore describe relations of the IPFIX framework to other architectures and frameworks. "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", Elisa Boschi, 21-May-07, This document describes a bandwidth saving method for exporting flow or packet information using the IP Flow Information Export (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well. This method works by separating information common to several flow records from information specific to an individual flow record. Common flow information is exported only once in a data record defined by an option template, while the rest of the specific flow information is associated with the common information via a unique identifier. "Guidelines for IP Flow Information eXport (IPFIX) Testing", Carsten Schmoll, Paul Aitken, Benoit Claise, 16-Apr-08, This document presents a list of tests for implementers of IP Flow Information Export (IPFIX) compliant Exporting Processes and Collecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes. "Definitions of Managed Objects for IP Flow Information Export", Thomas Dietz, Atsushi Kobayashi, Benoit Claise, 14-Jul-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, 14-Jul-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, 14-Jul-08, This document describes an extension to IPFIX to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise- specific Information Elements, facilitating interoperability and reusability among a wide variety of applications and tools. "IPFIX Mediation: Problem Statement", Atsushi Kobayashi, Haruhiko Nishida, Christoph Sommer, Falko Dressler, Emile Stephan, Benoit Claise, 26-Sep-08, Flow-based measurement is currently a popular method for various network monitoring usages. The sharing of flow-based information among orthogonal monitoring applications raises open issues in terms of scalability, reliability and flexibility that IPFIX Mediation may help resolve. IPFIX Mediation reroutes, replicates, filters, aggregates, correlates or modifies Flow Records or Packet Reports, or changes a transport protocol. This document describes the applicability of IPFIX Mediation and the problems that IPFIX Mediation might encounter. "IPFIX Mediation: Framework", Atsushi Kobayashi, Haruhiko Nishida, Benoit Claise, 30-Jun-08, This document describes a framework for an IPFIX Mediation. An IPFIX Mediation device (IPFIX Mediator) is an intermediate device between IPFIX Exporters and IPFIX Collectors. This framework describes an architecture model, the components of the architecture, and guidelines for the IPFIX protocol specifications for the IPFIX Mediators. In addition, this document describes applicable examples for IPFIX Mediation. "IPFIX Export per SCTP Stream", Benoit Claise, Paul Aitken, Andrew Johnson, Gerhard Muenz, 1-Jul-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. "Configuration Data Model for IPFIX and PSAMP", Gerhard Muenz, Benoit Claise, 4-Jul-08, This document specifies a data model for the configuration of caches, selection processes, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices. The configuration data model is encoded in Extensible Markup Language (XML). The structure of the data model is specified in a YANG module to ensure compatibility with the NETCONF protocol. A YANG-to-XSD converter is available which allows generating an XML Schema Definition (XSD) of the data model. IP Performance Metrics (ippm) ----------------------------- "A Two-way Active Measurement Protocol (TWAMP)", Jozef Babiarz, 4-Aug-08, The 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, 30-Sep-08, The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). "Spatial Composition of Metrics", Al Morton, Emile Stephan, 13-Jul-08, This memo utilizes IPPM metrics that are applicable to both complete paths and sub-paths, and defines relationships to compose a complete path metric from the sub-path metrics with some accuracy w.r.t. the actual metrics. This is called Spatial Composition in RFC 2330. The memo refers to the Framework for Metric Composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. "Reporting IP Performance Metrics to Users", Stanislav Shalunov, Martin Swany, 14-Jul-08, The aim of this document is to define a small set of metrics that are robust, easy to understand, orthogonal, relevant, and easy to compute. The IPPM WG has defined a large number of richly parameterized metrics because network measurement has many purposes. Often, the ultimate purpose is to report a concise set of metrics describing a network's state to an end user. It is for this purpose that the present set of metrics is defined. "Information Model and XML Data Model for Traceroute Measurements", Saverio Niccolini, Sandra Tartarelli, Juergen Quittek, Thomas Dietz, Martin Swany, 8-Oct-08, This document describes a standard way to store the configuration and the results of traceroute measurements. This document first of all describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined dividing the information elements in two semantically separated groups (configuration elements and results elements). Moreover an additional element is defined to relate configuration elements and results elements by means of a common unique identifier. On the basis of the information model a data model based on XML is defined to store the results of traceroute measurements. "A One-Way Packet Duplication Metric", Henk Uijterwaal, 7-Oct-08, When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive. In earlier work a metric for packet loss has been defined. This metric quantifies the case where a packet that is sent, does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. "Packet Delay Variation Applicability Statement", Al Morton, Benoit Claise, 13-Jul-08, Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions. Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. Intellectual Property Rights (ipr) ---------------------------------- "Advice to the Trustees of the IETF Trust on Rights to be Granted in IETF Documents", Joel Halpern, 13-Jul-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, 5-May-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 BCP 79 and RFC xxx (rfc editor - replace with the RFC # of -outgoing), replaces Section 10 of RFC 2026. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Internet Key Exchange Protocol: IKEv2", Charlie Kaufman, Paul Hoffman, Yoav Nir, Pasi Eronen, 26-Aug-08, This document describes version 2 of the Internet Key Exchange (IKE) protocol. It replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. IP Security Policy (ipsp) ------------------------- "IPsec Security Policy IPsec Action MIB", Wesley Hardaker, 10-Nov-06, This document defines an SMIv2 Management Information Base (MIB) module for configuring IPsec actions for the security policy database (SPD) of a device that uses the IPsec Security Policy Database Configuration MIB for configuring the IPSec protocol actions on that device. The IPsec Action MIB integrates directly with the IPsec Security Policy Database Configuration MIB and it is meant to work within the framework of an action referenced by that MIB. "IPsec Security Policy IKE Action MIB", Wesley Hardaker, 10-Nov-06, This document defines a SMIv2 Management Information Base (MIB) module for configuring Internet Key Exchange (IKE) actions for the security policy database (SPD) of a device that uses the IPsec Security Policy Database Configuration MIB for configuring the IKE protocol actions on that device. The IPsec IKE Action MIB integrates directly with the IPsec Security Policy Database Configuration MIB and it is meant to work within the framework of an action referenced by that MIB. IS-IS for IP Internets (isis) ----------------------------- "IPv6 Traffic Engineering in IS-IS", Jon Harrison, 26-Jun-08, This document specifies a method for exchanging IPv6 Traffic Engineering information using the IS-IS routing protocol. The described method uses three new TLVs, together with two new sub-TLVs of the Extended IS Reachability TLV. The information distributed allows a CSPF algorithm to calculate traffic engineered routes using IPv6 addresses. "Simplified Extension of LSP Space for IS-IS", Les Ginsberg, Stefano Previdi, Mike Shand, Danny McPherson, 25-Jun-08, 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. "Advertising Generic Information in IS-IS", Les Ginsberg, Stefano Previdi, Mike Shand, 20-Jun-08, This draft describes the manner in which generic application information (i.e. information not directly related to the operation of the IS-IS protocol) SHOULD be advertised in IS-IS LSPs and defines guidelines which SHOULD be used when flooding such information. Integrated Security Model for SNMP (isms) ----------------------------------------- "Secure Shell Transport Model for SNMP", David Harrington, Joseph Salowey, Wesley Hardaker, 7-Oct-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, 27-Aug-08, This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transports to include secure transports such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. "Transport Security Model for SNMP", David Harrington, Wesley Hardaker, 7-Oct-08, This memo describes a Transport Security Model for the Simple Network Management Protocol. This memo also defines a portion of the Management Information Base (MIB) for 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, 12-Oct-08, This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service by Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell Transport Model. Provisioning of Symmetric Keys (keyprov) ---------------------------------------- "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", Andrea Doherty, Mingliang Pei, Salah Machani, Magnus Nystrom, 12-Jul-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, 14-Jul-08, This document specifies a symmetric key format for transport and provisioning of symmetric keys (for example One Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of crypto modules such as a strong authentication device. The standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. This work is 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, 14-Jul-08, This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax can be used to digitally sign, digest, authenticate, or encrypt this content type. Kitten (GSS-API Next Generation) (kitten) ----------------------------------------- "Generic Security Service API Version 2 : Java Bindings Update", Mayan Upadhyay, Seema Malkani, 8-Jul-08, The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API version 2 : Java Bindings" (RFC2853). This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience. The GSS-API is described at a language independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS- API are "The Simple Public-Key GSS-API Mechanism" (RFC2025) and "The Kerberos Version 5 GSS-API Mechanism (RFC4121). "Clarifications and Extensions to the GSS-API for the Use of Channel Bindings", Nicolas Williams, 23-Sep-08, This document clarifies and generalizes the Generic Security Services Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. "GSS-API Naming Extensions", Nicolas Williams, Leif Johansson, 13-Jul-08, The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. Kerberos (krb-wg) ----------------- "Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals", Kenneth Raeburn, Larry Zhu, 14-Jul-08, The memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm TGT to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. "A Generalized Framework for Kerberos Pre-Authentication", Larry Zhu, Sam Hartman, 13-Jul-08, Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a mechanism called pre-authentication for proving the identity of a principal and for better protecting the long-term secret of the principal. This document describes a model for Kerberos pre-authentication mechanisms. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact. This document also provides common tools needed by multiple pre- authentication mechanisms. One of these tools is a secure channel between the client and the KDC with a reply key delivery mechanism; this secure channel can be used to protect the authentication exchange thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. "Anonymity Support for Kerberos", Larry Zhu, Paul Leach, 10-Oct-08, This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions which allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFC 4120, RFC 4121, and RFC 4556. "Additional Kerberos Naming Constraints", Larry Zhu, 12-Aug-08, This document defines new naming constraints for well-known Kerberos principal name and well-known Kerberos realm names. "PK-INIT algorithm agility", Love Astrand, Larry Zhu, 5-Aug-08, The PK-INIT defined in RFC 4556 is examined and updated to remove protocol structures tied to specific cryptographic algorithms. The affinity to SHA-1 as the checksum algorithm in the authentication request is analyzed. The PK-INIT key derivation function is made negotiable, the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide protection preemptively against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. "Kerberos Version 5 GSS-API Channel Binding Hash Agility", Shawn Emery, 14-Jul-08, Currently, channel bindings are implemented using a MD5 hash in the Kerberos Version 5 Generic Security Services Application Programming Interface (GSS-API) mechanism [RFC4121]. This document updates RFC4121 to allow the channel binding restriction to be lifted using algorithms negotiated based on Kerberos crypto framework as defined in RFC3961. In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions. "OTP Pre-authentication", Gareth Richards, 15-Sep-08, The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One Time Password (OTP) authentication. "An information model for Kerberos version 5", Leif Johansson, 10-Jul-08, This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a kerberos 5 KDC. This document describes the services exposed by an administrative interface to a KDC. Layer 1 Virtual Private Networks (l1vpn) ---------------------------------------- "OSPFv3 Based Layer 1 VPN Auto-Discovery", Lou Berger, 8-Aug-08, This document defines an Open Shortest Path First (OSPF) version 3 based Layer-1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3)", Carlos Pignataro, 10-Jul-08, This document describes the use of "version 3" of Layer Two Tunneling Protocol (L2TPv3) to tunnel Point-to-Point Protocol (PPP) packets. This document defines the control protocol and encapsulation specifics for tunneling PPP over L2TPv3, and is a companion document to the L2TPv3 base specification. "Layer Two Tunneling Protocol - Setup of TDM Pseudowires", Sharon Galtzur, Alexander Vainshtein, 19-Jun-08, This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for support of structure-agnostic and structure-aware TDM pseudowires. "L2TPv3 Extended Circuit Status Values", Neil McGill, Carlos Pignataro, 29-Sep-08, This document defines additional Layer 2 Tunneling Protocol Version 3 (L2TPv3) bit values to be used within the "Circuit Status" Attribute Value Pair (AVP) to communicate more granular error states for Access Circuits and Pseudowires. It also deprecates the use of the New bit in the "Circuit Status" AVP, updating RFC3931. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- "Provisioning, Autodiscovery, and Signaling in L2VPNs", Eric Rosen, 5-May-06, Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol (L2TPv3). "L2VPN OAM Requirements and Framework", Dinesh Mohan, Ali Sajassi, Simon Delord, Philippe Niger, 14-Jul-08, This draft provides framework and requirements for Layer 2 Virtual Private Networks (L2VPN) Operation, Administration and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN) tunnels. The requirements are intended to identify OAM requirement for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if L2VPN services OAM requirements impose specific requirements on PWOAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. "Requirements for Multicast Support in Virtual Private LAN Services", Yuji Kamite, Yuichiro Wada, Yetik Serbest, Thomas Morin, Luyuan Fang, 5-Aug-08, This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. "Multicast in VPLS", Rahul Aggarwal, Yuji Kamite, Luyuan Fang, Yakov Rekhter, Intellectual Property, 2-Jun-08, This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSs are also described. "VPLS Interoperability with CE Bridges", Dinesh Mohan, Ali Sajassi, 29-Sep-08, One of the main motivations behind VPLS is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers. When CE devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have currently been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This draft extends the PE model described in RFC 4664 based on IEEE 802.1ad bridge module and illustrates a clear demarcation between IEEE bridge module and IETF LAN emulation module. By doing so, it describes that the majority of interoperability issues with CE bridges can be delegated to 802.1ad bridge module, thus removing the burden on IETF LAN emulation module within a VPLS PE. "Virtual Private Lan Services (VPLS) Management Information Base", Rohit Mediratta, Thomas Nadeau, Kiran Koushik, 15-Jul-08, This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Virtual Private LAN services. It needs to be used in conjunction with Pseudo Wire (PW) Management Information Base [PWE3-PW-MIB]. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Sarveshwar Bandi, Yiqun Cai, Thomas Morin, Yakov Rekhter, Eric Rosen, IJsbrand Wijnands, Seisho Yasukawa, 10-Jul-08, In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Eric Rosen, Thomas Morin, Yakov Rekhter, Intellectual Property, 16-Jun-08, This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN]. "Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN", Kenji Kumaki, Yuji Kamite, Raymond Zhang, 14-Jul-08, Some service providers want to build a service which guarantees QoS or bandwidth from a local CE to a remote CE through the network. Today, customers expect to run triple play services through BGP/MPLS IP-VPNs. As a result, their requirements for end-to-end QoS of applications are increasing. Depending on the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.), an end-to-end native RSVP path and/or an end-to-end MPLS TE LSP are required, and they need to meet some constraints. This document describes service provider requirements for supporting customer RSVP and RSVP-TE over a BGP/MPLS VPN. "Four-octet AS Specific BGP Extended Community", Yakov Rekhter, Srihari Sangli, Dan Tappan, 29-Sep-08, This document defines a new type of a BGP extended community - four- octet AS specific extended community. This community allows to carry 4 octet autonomous system numbers. "IPv6 Address Specific BGP Extended Communities Attribute", Yakov Rekhter, 29-Sep-08, Current specifications of BGP Extended Communities [BGP-EXTCOMM] support IPv4 Address Specific Extended Community, but do not support IPv6 Address Specific Extended Community. The lack of IPv6 Address Specific Extended Community may be a problem when an application uses IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, IPv6 Address Specific Extended Community that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. "BGP ACCEPT_OWN Standards Action Community Attribute", James Uttaro, Pradosh Mohapatra, David Smith, Robert Raszuk, John Scudder, Intellectual Property, 5-Oct-08, Under certain conditions it is desirable for a BGP route reflector to be able to modify the Route Target list of a VPN route that is distributed by the route reflector, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same PE as the VRF(s) that import the route. However, due to the constraints of the BGP protocol, it does not work if the two are on the same PE. This document describes a modification to the BGP protocol allowing this technique to work when the VRFs are on the same PE, allowing the technique to be used in a standard manner throughout an autonomous system. "OSPFv3 as a PE-CE routing protocol", Padma Pillay-Esnault, Peter Moyer, Jeff Doyle, Emre Ertekin, Michael Lundberg, 6-Oct-08, Many Service Providers (SPs) offer the Virtual Private Network (VPN) services to their customers, using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. Enhancements to Internet email to Support Diverse Service Environments (lemonade) --------------------------------------------------------------------------------- "Lemonade Notifications Architecture", Randall Gellens, Stephane Maes, 8-Jul-08, This document discusses how to provide notification and filtering mechanisms to mail stores to meet Lemonade goals. This document also discusses the use of server to server notifications, and how server to server notifications fit into an architecture which provides server to client notifications. Gellens [page 1] Expires January 2009 Internet Draft Lemonade Notifications Architecture July 2008 "The Lemonade Profile", Dave Cridland, Alexey Melnikov, Stephane Maes, 30-Sep-08, This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon several extensions to IMAP and Mail Submission protocols. "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, 10-Jul-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, 26-Sep-08, This document describes a method for streaming multimedia attachments received by a resource constrained and/or mobile device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio e-mail content. The document describes a profile for making use of the IMAP URLAUTH extension (RFC 4467), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022). "IMAP4 extension for named searches (filters)", Alexey Melnikov, Curtis King, 22-Sep-08, The document defines a way to persistently store named IMAP (RFC 3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criteria as a parameter. "The IMAP NOTIFY Extension", Arnt Gulbrandsen, Alexey Melnikov, Curtis King, 19-Aug-08, This document defines an IMAP extension which allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from mailboxes. [[Add Updates: RFC-CONTEXT to the headers]] "LEMONADE Architecture - Supporting OMA Mobile Email (MEM) using Internet Mail", Eric Burger, Glenn Parsons, 9-Jul-08, 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. "Extended URLFETCH for binary and converted parts", Dave Cridland, 4-Sep-08, The URLFETCH command defined as part of URLAUTH provides a mechanism for third-parties to gain access to data held within messages in a user's private store, however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications. Long-Term Archive and Notary Services (ltans) --------------------------------------------- "Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC)", Thomas Kunz, Susanne Okunick, Ulrich Pordesch, 8-Oct-08, In many application areas it must be possible to prove the existence and integrity of digital signed data. This proof depends on the security suitability of the cryptographic algorithms used to generate or verify the digital signature. Because algorithms can become weak over the years, it is necessary to periodically evaluate these security suitabilities. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitabilities of cryptographic algorithms. Language Tag Registry Update (ltru) ----------------------------------- "Tags for Identifying Languages", Addison Phillips, Mark Davis, 17-Sep-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, 29-Sep-08, This memo defines the procedure used to update the IANA Language Subtag Registry in conjunction with the publication of RFC 4646bis [RFC EDITOR NOTE: replace with actual RFC number], for use in forming tags for identifying languages. As an Internet-Draft, it also contained a complete replacement of the contents of the Registry to be used by IANA in updating it. To prevent confusion, this material was removed before publication. Multicast & Anycast Group Membership (magma) -------------------------------------------- "Multicast Group Membership Discovery MIB", Julian Chesterfield, 16-Sep-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. Mobile Ad-hoc Networks (manet) ------------------------------ "Dynamic MANET On-demand (DYMO) Routing", Ian Chakeres, Charles Perkins, 24-Jun-08, The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile routers in wireless, multihop networks. DYMO determines unicast routes among DYMO routers within the network in an on-demand fashion, offering improved convergence in dynamic topologies. "The Optimized Link State Routing Protocol version 2", Thomas Clausen, Christopher Dearlove, Philippe Jacquet, 10-Jul-08, This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol. The protocol embodies an optimization of the classical link state algorithm tailored to the requirements of a Mobile Ad hoc NETwork (MANET). The key optimization in OLSRv2 is that of multipoint relays (MPRs), providing an efficient mechanism for network-wide broadcast of link state information (i.e. reducing the cost of performing a network- wide link state broadcast). A secondary optimization is that OLSRv2 employs partial link state information; each node maintains information about all destinations, but only a subset of links. Consequently, only selected nodes flood link state advertisements (thus reducing the number of network-wide link state broadcasts) and these advertisements contain only a subset of links (thus reducing the size of network-wide link state broadcasts). The partial link state information thus obtained still allows each OLSRv2 node to at all times maintain optimal (in terms of number of hops) routes to all destinations in the network. OLSRv2 imposes minimum requirements on the network by not requiring sequenced or reliable transmission of control traffic. Furthermore, the only interaction between OLSRv2 and the IP stack is routing table management. OLSRv2 is particularly suitable for large and dense networks as the technique of MPRs works best in this context. "Generalized MANET Packet/Message Format", Thomas Clausen, Christopher Dearlove, Justin Dean, Cedric Adjih, 26-Sep-08, This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. "MANET Neighborhood Discovery Protocol (NHDP)", Thomas Clausen, Christopher Dearlove, Justin Dean, 10-Jul-08, This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). "IANA Allocations for MANET Protocols", Ian Chakeres, 18-Nov-07, This document enumerates several common IANA allocations for use by MANET protocols. The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address. "Representing multi-value time in MANETs", Thomas Clausen, Christopher Dearlove, 26-Sep-08, This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized MANET packet/message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. "Definition of Managed Objects for the DYMO Manet Routing Protocol", Sean Harnedy, Robert Cole, Ian Chakeres, 15-May-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the DYMO routing process. The DYMO MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting routing problems. MBONE Deployment (mboned) ------------------------- "Automatic IP Multicast Without Explicit Tunnels (AMT)", Dave Thaler, Mohit Talwar, Amit Aggarwal, Lorenzo Vicisano, Tom Pusateri, 27-Jun-08, Automatic Multicast Tunneling (AMT) allows multicast communication amongst isolated multicast-enabled sites or hosts, attached to a network which has no native multicast support. It also enables them to exchange multicast traffic with the native multicast infrastructure and does not require any manual configuration. AMT uses an encapsulation interface so that no changes to a host stack or applications are required, all protocols (not just UDP) are handled, and there is no additional overhead in core routers. "IANA Guidelines for IPv4 Multicast Address Assignments", Michelle Cotton, Dave Meyer, 24-Jun-08, This document obsoletes RFC 3171. It provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. "Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s)", Haixiang He, 20-Jun-08, This memo presents requirements in the area of accounting and access control for IP multicasting. The scope of the requirements is limited to cases that Authentication, Accounting and Authorization (AAA) functions are coordinated between Content Provider(s) and Network Service Provider(s). General requirements for accounting and admission control capabilities including quality-of-service (QoS) related issues are listed. This memo assumes that these capabilities can be realized by functions implemented at edges of a network based on IGMP or MLD. Finally, cases for Content Delivery Services (CDS) are described as application examples which could benefit from multicasting accounting and access control capabilities as described in this memo. This memo defines requirements related to AAA issues for multi- entity provider models in which the network service provider and content provider cooperate to provide CDS and various related AAA functions for purposes such as protecting and accounting for the access to content and network resources. The requirements are generally not relevant to cases in which there is not a reason to share AAA functions between separate entities. "AAA and Admission Control Framework for Multicasting", Hiroaki Satou, 2-Jul-08, IP multicast-based services, such as TV broadcasting or videoconferencing raise the issue of making sure that potential customers are fully entitled to access the corresponding contents. There is indeed a need for service and content providers to identify users (if not authenticate, especially within the context of enforcing electronic payment schemes) and to retrieve statistical information for accounting purposes, as far as content and network usage are concerned. This memo describes the framework for specifying the Authorization, Authentication and Accounting (AAA) capabilities that could be activated within the context of the deployment and the operation of IP multicast-based services. This framework addresses the requirements presented in "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services" [I-D.mboned-maccnt-req]. The memo provides a basic AAA enabled model as well as an extended fully enabled model with resource and admission control coordination. "Lightweight IGMPv3 and MLDv2 Protocols", Hui Liu, Wei Cao, Hitoshi Asaeda, 6-Sep-08, This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. "Multicast Ping Protocol", Stig Venaas, 18-Sep-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, 8-Jul-08, This document describes the IP multicast traceroute facility. Unlike unicast traceroute, multicast traceroute requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how management applications can use the router functionality. Media Server Control (mediactrl) -------------------------------- "Media Control Channel Framework", Chris Boulton, Tim Melanchuk, Scott McGlashan, 20-Aug-08, This document describes a Framework and protocol for application deployment where the application programming logic and processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co- located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers. The motivation for the creation of this Framework is to provide an interface suitable to meet the requirements of a distributed, centralized conference system, as defined by the IETF. It is not, however, limited to this scope and it is envisioned that this generic Framework will be used for a wide variety of de-coupled control architectures between network entities. "An Architectural Framework for Media Server Control", Tim Melanchuk, 17-Apr-08, This document describes an Architectural Framework for Media Server Control. The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them. "SIP Interface to VoiceXML Media Services", Dave Burke, Mark Scott, 8-Jul-08, This document describes a SIP interface to VoiceXML media services. Commonly, application servers controlling media servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism.Comments Please send comments on this draft to the MEDIACTRL mail list, mediactrl@ietf.org. "An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework", Scott McGlashan, Tim Melanchuk, Chris Boulton, 7-Oct-08, This document defines a Media Control Channel Framework Package for Interactive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting and terminating dialog interactions, as well as associated responses and notifications. Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, DTMF collect and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs. "A Mixer Control Package for the Media Control Channel Framework", Tim Melanchuk, Scott McGlashan, Chris Boulton, 6-Jul-08, This document defines a Mixer Control Package for the Media Control Channel Framework. This Control Package aims to fulfill Conferencing requirements using the SIP Control Framework. Mobility EXTensions for IPv6 (mext) ----------------------------------- "Analysis of Multihoming in Mobile IPv6", Nicolas Montavont, Ryuji Wakikawa, Thierry Ernst, Chan-Wah Ng, Koojana Kuladinithi, 2-May-08, 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. "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", Thierry Ernst, Nicolas Montavont, Ryuji Wakikawa, Chan-Wah Ng, Koojana Kuladinithi, 2-May-08, In this document, multihoming is investigated from an end-node point of view, and not from a site point of view as the term "multihoming" is commonly understood so far. The purpose of this document is to explain the motivations for fixed and mobile nodes (hosts and routers) using multiple interfaces and the scenarios where this may end up using multiple global addresses on their interfaces. Such multihoming configurations can bring a number of benefits once appropriate support mechanisms are put in place. Interestingly, this analysis is generic, i.e. motivations and benefits of node multihoming apply to both fixed end nodes and mobile end nodes. "Multiple Care-of Addresses Registration", Ryuji Wakikawa, Vijay Devarapalli, Thierry Ernst, Kenichi Nagami, 27-Aug-08, According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. "Home Agent Reliability Protocol", Ryuji Wakikawa, 14-Jul-08, The home agent can be a single point of failure when Mobile IPv6 is operated in a system. It is critical to provide home agent reliability in the event of a home agent crashing or becoming unavailable. This would allow another home agent to take over and continue providing service to the mobile nodes. This document describes the problem scope briefly and provides a mechanism of home agent failure detection, home agent state transfer, and home agent switching for home agent redundancy and reliability. "RADIUS Mobile IPv6 Support", Avi Lior, Kuntal Chowdhury, Hannes Tschofenig, 14-Jul-08, This document defines new attributes to facilitate Mobile IPv6 operations using RADIUS infrastructure. The operations include bootstrapping of information required by the Mobile Node and the interface between the Network Access Server, Home Agent and the RADIUS server used to assist MIP6 operations. "NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", Wesley Eddy, Will Ivancic, Terry Davis, 13-May-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, 2-May-08, In commercial and enterprise deployments Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the AAA infrastructure (e.g. NAS and AAA server) offers also a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. "Mobile IPv6 Support for Dual Stack Hosts and Routers", Hesham Soliman, 14-Jul-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, 4-May-08, This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile ipv6 node with NEMO functionality. "Automotive Industry Requirements for NEMO Route Optimization", Roberto Baldessari, Thierry Ernst, Andreas Festag, Massimiliano Lenardi, 14-Jul-08, This document specifies requirements for NEMO Route Optimization techniques as identified by the automotive industry. Requirements are gathered from the Car2Car Communication Consortium and ISO Technical Committee 204 Working Group 16 (CALM). "Flow Bindings in Mobile IPv6 and Nemo Basic Support", Hesham Soliman, Nicolas Montavont, Niko Fikouras, Koojana Kuladinithi, 16-May-08, 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. "Mobility Support in IPv6", David Johnson, Charles Perkins, Jari Arkko, 1-Oct-08, This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. "DHCPv6 Prefix Delegation for NEMO", Ralph Droms, Pascal Thubert, Francis Dupont, Wassim Haddad, 17-Jun-08, One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. "Binding Revocation for IPv6 Mobility", Ahmad Muhanna, Mohamed Khalil, Sri Gundavelli, Kuntal Chowdhury, Parviz Yegani, 28-Aug-08, This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. "Mobile IPv6 Generic Signaling Message", Brian Haley, Sri Gundavelli, 14-Aug-08, This document specifies two new Mobility Header message types that allow Mobile IPv6 entities to send and receive generic signaling messages. Haley Expires - January 2008 [page 1] Mobile IPv6 Generic Signaling Message August 2008 "Guidelines for firewall administrators regarding MIPv6 traffic", Suresh Krishnan, Niklas Steinleitner, QIU Ying, Gabor Bajko, 10-Oct-08, This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability. "Guidelines for firewall vendors regarding MIPv6 traffic", Suresh Krishnan, Yaron Sheffer, Niklas Steinleitner, Gabor Bajko, 10-Oct-08, This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6. Mobility for IPv4 (mip4) ------------------------ "The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised", Kent Leung, Ravindra Rathi, Hans Sjostrand, 7-Aug-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. "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. "Generic Notification Message for Mobile IPv4", Hui Deng, Henrik Levkowetz, Vijay Devarapalli, Sri Gundavelli, Brian Haley, 13-Jul-08, This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a new Mobile IPv4 message type designed for this purpose. "Dynamic Prefix Allocation for NEMOv4", George Tsirtsis, Vincent Park, Vidya Narayanan, Kent Leung, 29-Aug-08, The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism. "FA extensions to NEMOv4 Base", George Tsirtsis, Vincent Park, Vidya Narayanan, Kent Leung, 25-Apr-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. "The Definitions of Managed Objects for Mobile IP UDP Tunneling", Hans Sjostrand, 11-Aug-08, This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent when Mobile IP Traversal of Network Address Translation (NAT) Devices are used. Mobility for IPv6 (mip6) ------------------------ "Using IPsec between Mobile and Correspondent IPv6 Nodes", Francis Dupont, Jean-Michel Combes, 25-Aug-08, Mobile IPv6 uses IPsec to protect signaling between the Mobile Node and the Home Agent. This document defines how IPsec can be used between the Mobile Node and Correspondent Nodes for Home Address Option validation and protection of mobility signaling for Route Optimization. The configuration details for IPsec and IKE are also provided. "Why Authentication Data suboption is needed for MIP6", Basavaraj Patil, Gopal Dommety, 14-Jul-08, Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec SA that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the binding update and binding acknowledgement messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism was needed for Mobile IPv6 deployment in certain environments. "MIP6-bootstrapping for the Integrated Scenario", Kuntal Chowdhury, Alper Yegin, 21-Apr-08, Mobile IPv6 bootstrapping can be categorized into two primary scenarios, the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. "DHCP Options for Home Information Discovery in MIPv6", Hee-Jin Jang, Alper Yegin, Kuntal Chowdhury, JinHyeock Choi, 22-May-08, This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined which allow a mobile node to request the home agent IP address, FQDN, or home network prefix and obtain it via the DHCP response. Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) -------------------------------------------------------------------------- "Mobility Services Framework Design (MSFD)", Telemaco Melia, Gabor Bajko, Subir Das, Nada Golmie, Juan Zuniga, 24-Sep-08, This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document also describes mechanisms for mobility service (MoS) discovery and transport layer mechanisms for the reliable delivery of MIH messages. "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Mobility Server (MoS) discovery", Gabor Bajko, Subir Das, 5-Sep-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 [MSFD]. These Mobility Services are used to assist an MN in handover preparation (network discovery) and handover decision (network selection). The services addressed in this document are the Media Independent Handover Services defined in [IEEE802.21]. "Locating Mobility Servers using DNS", Gabor Bajko, 22-Sep-08, This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers which provide 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]. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Real Time Streaming Protocol 2.0 (RTSP)", Henning Schulzrinne, Anup Rao, Rob Lanphier, Magnus Westerlund, Martin Stiemerling, 5-May-08, This memorandum defines RTSP version 2.0 which is a revision of the Proposed Standard RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). "An Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP)", Jeff Goldberg, Magnus Westerlund, Thomas Zeng, 14-Jul-08, This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Jonathan Rosenberg, 29-Oct-07, This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). "An Extension to the Session Description Protocol (SDP) for Media Loopback", Kaynam Hedayat, 4-Aug-08, The wide deployment of Voice over IP (VoIP), Real-time Text and Video over IP services has introduced new challenges in managing and maintaining voice/real-time Text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, service providers are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes which enables establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video Over IP performance metrics. "TCP Candidates with Interactive Connectivity Establishment (ICE)", Jonathan Rosenberg, 14-Jul-08, Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", Miguel Garcia-Martin, Markus Isomaki, Gonzalo Camarillo, Salvatore Loreto, Paul Kyzivat, 20-May-08, This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. "SDP Capability Negotiation", Flemming Andreasen, 11-Jul-08, The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g. RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation. The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner. The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g. media types and media formats) may be provided in other documents. "SDP media capabilities Negotiation", Robert Gilman, Roni Even, Flemming Andreasen, 14-Jul-08, Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. This extension is designed to map easily to existing and future SDP media attributes. "The evaluation of different NAT traversal Techniques for media controlled by Real-time Streaming Protocol (RTSP)", Magnus Westerlund, Thomas Zeng, 11-Jul-08, This document describes several NAT traversal techniques that could be used by RTSP. Each technique includes a description on how it would be used, the security implications of using it and any other deployment considerations it has. There are also disussions on how NAT traversal techniques relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP solution to standardize in the MMUSIC WG. "Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)", James Polk, Subha Dhesikan, Gonzalo Camarillo, 10-Oct-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. "Signaling media decoding dependency in Session Description Protocol (SDP)", Thomas Schierl, Stephan Wenger, 25-Sep-08, This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streamsas a result of the use of a layered or multiple descriptive media coding process. A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). "SDP: Session Description Protocol", Mark Handley, 9-Jun-08, This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Brian Stucker, Hannes Tschofenig, 14-Jul-08, Middleboxes are defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. Two such functions are network address translation and firewalling. When Application Layer Gateways, such as SIP entities, interact with NATs and firewalls, as described in the MIDCOM architecture, then problems may occur in the transport of media traffic when signaling protocol interaction takes place along the media path, as it is the case for recent key exchange proposals (such as DTLS-SRTP). This document highlights problems that may arise. Unfortunately, it is difficult for the end points to detect or predict problematic behavior and to determine whether the media path is reliably available for packet exchange. This document aims to summarize the various sources and effects of NAT and firewall control, the reasons that they exist, and possible means of improving their behavior to allow protocols that rely upon signaling along the media path to operate effectively. "The SDP (Session Description Protocol) Grouping Framework", Gonzalo Camarillo, 6-Jul-08, In this specification, we define a framework to group "m" lines in SDP (Session Description Protocol) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. Multiprotocol Label Switching (mpls) ------------------------------------ "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", Riza Cetin, Thomas Nadeau, Kiran Koushik, 29-Sep-08, This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method. "MPLS Traffic Engineering Soft Preemption", Denver Maddux, Curtis Villamizar, Amir Birjandi, and Swallow, JP Vasseur, 22-Sep-08, This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing/ eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially MPLS RSVP-TE was defined supporting only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the re-route process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be re-routed. For this reason, the feature is primarily but not exclusively interesting in MPLS enabled IP networks with Differentiated Services and Traffic Engineering capabilities. "Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping", Seisho Yasukawa, Adrian Farrel, Zafar Ali, Bill Fenner, George Swallow, Thomas Nadeau, 10-Sep-08, Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. "Component Link Recording and Resource Control for TE Link Bundles", Intellectual Property, 6-Jul-08, Record Route is a useful administrative tool that has been used extensively by the service providers. However, when TE links are bundled, identification of label resource in Record Route Object (RRO) is not enough for the administrative purpose. Network service A.Zamfir et al. - Expires Janury 2009 [page 1] Component Link Record. & Resource Control for TE Link Bundles Jul.2008 providers would like to know the component link within a TE link that is being used by a given LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along with the TE link identifier and Label. As it is not possible to record component link in the RRO, this draft defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for resource recording purposes. This draft also defines the Explicit Route Object (ERO) counterpart of the RRO extension. The ERO extensions are needed to perform explicit label/ resource control over bundled TE link. Hence, this document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for explicit resource control and recording over TE link bundles. "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Ina Minei, 30-Jun-08, This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver- initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/MP2MP LSP is outside the scope of this document. "MPLS Upstream Label Assignment for RSVP-TE", Rahul Aggarwal, Jean-Louis Le Roux, 8-Jul-08, This document describes procedures for distributing upstream-assigned labels for Resource Reservation Protocol - Traffic Engineering (RSVP- TE). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for RSVP-TE point-to- multipoint (P2MP)LSPs. "MPLS Upstream Label Assignment for LDP", Rahul Aggarwal, Jean-Louis Le Roux, 8-Jul-08, This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. "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, and Swallow, Kenji Kumaki, Alberto Bonda, 1-Sep-08, Several Link-type sub-Type-Lenght-Values (sub-TLVs) have been defined for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (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 assumptions 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, 30-Apr-08, This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The MIB module defined in this document is applicable to P2MP MPLS-TE by extensions to the MPLS-TE MIB module defined in RFC 3812. It is equally applicable to P2MP Generalized MPLS (GMPLS) in association with the GMPLS TE MIB module defined in RFC 4802. "Proxy LSP Ping", George Swallow, Vanson Lim, Intellectual Property, 14-Jul-08, This document defines a means of remotely initiating Multiprocal Label Switched Protocol Pings on Label Switched Paths. A proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to root tracing.Contents "LDP Capabilities", Bob Thomas, 26-Mar-08, A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. At present LDP has no guidelines for advertising such enhancements at LDP session initialization time. There is also no mechanism to enable and disable enhancements after the session is established. This document provides guidelines for advertising LDP enhancements at session initialization time. It also defines a mechanism to enable and disable enhancements after LDP session establishment. "Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message", JP Vasseur, George Swallow, Ina Minei, 18-Aug-08, The aim of this document is to describe a common practice with regard to the behavior of a node sending a Resource ReserVation Protocol (RSVP) Traffic Engineering (TE) Path Error message and to the behavior of a node receiving an RSVP Path Error message for a preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering Label Switched Path (TE LSP). This document does not define any new protocol extensions. "Security Framework for MPLS and GMPLS Networks", Luyuan Fang, Michael Behringer, 13-Jul-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 Fang, et al. Informational [page 1] MPLS/GMPLS Security framework July 2008 MPLS and GMPLS networks across different domains or different Service Providers. "Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs", Zafar Ali, George Swallow, 19-Jun-08, Expires December 2008 [page 1] Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt There are many deployment scenarios which require Egress LSR to receive binding of the RSVP-TE LSP to an application, and payload identification, using some "out-of-band" (OOB) mechanism. This document proposes protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to- multipoint (P2MP) LSPs. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "An Analysis of Scaling Issues in MPLS-TE Core Networks", Seisho Yasukawa, Adrian Farrel, Olufemi Komolafe, 19-Jun-08, Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning. This document presents an analysis of some of the scaling concerns for MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies, and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks. This document considers only scalability for point-to-point MPLS-TE. Point-to-multipoint MPLS-TE is for future study. "LDP IGP Synchronization", Markus Jork, Alia Atlas, Luyuan Fang, 30-Jun-08, In certain networks there is a dependency on edge-to-edge LSPs setup by LDP, e.g. networks that are used for MPLS VPN applications. For such applications it is not possible to rely on IP forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the IGP is operational on a link but LDP is not operational on that link. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN; BGP route free core; or IP address carried in the packet is out of the RFC1918 space. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. ""EXP field" renamed to "CoS Field"", Loa Andersson, 7-Jul-08, The early MPLS documents defined the form of the MPLS Label Stack entry. This include a three bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use". Although the intended use of the EXP field was as a "Class of Service" field, it was not named the "Class of Service" (CoS) field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. . To avoid misunderstanding about how this field may be used, this document changes the name of the field to the "CoS field". In doing so it also updates documents that define the current use of the EXP this field. "Mechanism for performing LSP-Ping over MPLS tunnels", Nitin Bahadur, Kireeti Kompella, George Swallow, 21-Sep-08, This document describes methods for performing lsp-ping traceroute over mpls tunnels and for traceroute of stitched mpls LSPs. The techniques outlined in RFC 4379 are insufficient to perform traceroute FEC validation and path discovery for a LSP that goes over other mpls tunnels or for a stitched LSP. This document describes enhancements to the downstream-mapping TLV (defined in RFC 4379). These enhancements along with other procedures outlined in this document can be used to trace such LSPs. "LDP End-of-LIB", Rajiv Asati, Pradosh Mohapatra, Bob Thomas, Emily Chen, 15-Sep-08, There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. "PathErr Message Triggered MPLS and GMPLS LSP Reroute", Lou Berger, Dimitri Papadimitriou, JP Vasseur, 19-Sep-08, This document describes how Resource ReserVation Protocol (RSVP) PathErr Messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definition can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute application-specific error values. Multicast Security (msec) ------------------------- "Multicast Extensions to the Security Architecture for the Internet Protocol", Brian Weis, George Gross, Dragan Ignjatic, 6-Jun-08, The Security Architecture for the Internet Protocol describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets. This document describes how the IPsec security services are applied to IP multicast packets. These extensions are relevant only for an IPsec implementation that supports multicast. "Use of TESLA in the ALC and NORM Protocols", Vincent Roca, Aurelien Francillon, Sebastien Faurite, 30-Jul-08, This document details the TESLA packet source authentication and packet integrity verification protocol and its integration within the ALC and NORM content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", David McGrew, Brian Weis, 9-Jun-08, Advanced Encryption Standard (AES) counter modes use a counter, which is typically assumed to be incremented by a single sender. This memo describes the use of AES counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. Network Endpoint Assessment (nea) --------------------------------- "PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC", Ravi Sahita, Stephen Hanna, Kaushik Narayan, 14-Jul-08, This document specifies PB-TNC, a Posture Broker Protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification. "PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC", Kaushik Narayan, Paul Sangster, 9-Oct-08, This document specifies PA-TNC, a Posture Attribute Protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. Network Configuration (netconf) ------------------------------- "NETCONF over Transport Layer Security (TLS)", Mohamad Badra, Ibrahim Hajjeh, 4-Sep-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, 8-Aug-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, Martin Bjorklund, 25-Jun-08, 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 discover all possible data models (schema list retrieval) and a mechanism to retrieve schema via NETCONF (get schema). Both can be performed dynamically throughout a session, unlike capabilities exchange which is performed during session setup only. Both support multiple schema versions, formats and locations. Network-based Localized Mobility Management (netlmm) ---------------------------------------------------- "IPv4 Support for Proxy Mobile IPv6", Ryuji Wakikawa, Sri Gundavelli, 23-Sep-08, This document specifies extensions to Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) extending IPv4 home address mobility support to the mobile node. 2) allowing the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network. "GRE Key Option for Proxy Mobile IPv6", Ahmad Muhanna, Mohamed Khalil, Sri Gundavelli, Kent Leung, 7-Oct-08, This document defines a new Mobility Option for allowing the mobile access gateway and the local mobility anchor to negotiate GRE encapsulation mode and exchange the downlink and uplink GRE keys which are used for marking the downlink and uplink traffic that belong to a specific mobile node session or a specific flow. "Heartbeat Mechanism for Proxy Mobile IPv6", Vijay Devarapalli, Rajeev Koodli, Heeseon Lim, Nishi Kant, Suresh Krishnan, Julien Laganier, 30-Sep-08, Proxy Mobile IPv6 is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA), setup tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures quickly and take appropriate action. NETCONF Data Modeling Language (netmod) --------------------------------------- "YANG - A data modeling language for NETCONF", Martin Bjorklund, 29-Aug-08, YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. "Common YANG Data Types", Juergen Schoenwaelder, 4-Sep-08, This document introduces a collection of common data types to be used with the YANG data modeling language. Network File System Version 4 (nfsv4) ------------------------------------- "RPC: Remote Procedure Call Protocol Specification Version 2", Robert Thurlow, 10-Jun-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, 16-Apr-08, A protocol is described providing Remote Direct Memory Access (RDMA) as a new transport for Remote Procedure Call (RPC). The RDMA transport binding conveys the benefits of efficient, bulk data transport over high speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. "NFS Direct Data Placement", Thomas Talpey, Brent Callaghan, Intellectual Property, 16-Apr-08, This draft defines the bindings of the various Network File System (NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2, 3, 4 and 4.1 over such an RDMA transport. "NFS Version 4 Minor Version 1", Spencer Shepler, Mike Eisler, David Noveck, 5-Sep-08, This Internet-Draft describes NFS version 4 minor version one, including features retained from the base protocol and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version one include: Sessions, Directory Delegations, and parallel NFS (pNFS). "pNFS Block/Volume Layout", David Black, Stephen Fridella, Jason Glasgow, 11-Jun-08, Parallel NFS (pNFS) extends NFSv4 to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations draft specifies storage-class-independent extensions to NFS; this draft specifies the additional extensions (primarily data structures) for use of pNFS with block and volume based storage. "Object-based pNFS Operations", Benny Halevy, Brent Welch, Jim Zelenka, 19-Jun-08, This Internet-Draft provides a description of the object-based pNFS extension for NFSv4. This is a companion to the main pnfs specification in the NFSv4 Minor Version 1 Internet Draft, which is currently draft-ietf-nfsv4-minorversion1-23. "NFSv4 Minor Version 1 XDR Description", Spencer Shepler, Mike Eisler, David Noveck, 5-Sep-08, This Internet-Draft provides the XDR description for NFSv4 minor version one. "RPCSEC_GSS Version 2", Mike Eisler, 9-Oct-08, This Internet-Draft describes version 2 of the RPCSEC_GSS protocol. Version 2 is the same as Version 1 but adds support for channel bindings. "IANA Considerations for RPC Net Identifiers and Universal Address Formats", Mike Eisler, 19-Aug-08, This Internet-Draft lists IANA Considerations for RPC Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This Internet-Draft updates, but does not replace, RFC1833. "Using DNS SRV to Specify a Global File Name Space with NFS version 4", Craig Everhart, Andy Adamson, Jiaying Zhang, 26-Sep-08, The NFS version 4 protocol provides a natural way for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple and appropriate way for an organization to publish the root of its name space, even to clients that might not be intimately associated with such an organization. DNS SRV can be used to join these organization-wide file name spaces together to allow construction of a global, uniform NFS version 4 file name space. This document refreshes the draft. "Administration Protocol for Federated Filesystems", Daniel Ellard, Craig Everhart, James Lentini, Renu Tewari, Manoj Naik, 26-Sep-08, This document describes the administration protocol for a federated file system that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers and collections of fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. "Requirements for Federated File Systems", Daniel Ellard, Craig Everhart, James Lentini, Renu Tewari, Manoj Naik, 26-Sep-08, This draft describes and lists the functional requirements of a federated file system and defines related terms. Our intent is to use this draft as a starting point and refine it, with input and feedback from the file system community and other interested parties, until we reach general agreement. We will then begin, again with the help of any interested parties, to define standard, open federated file system protocols that satisfy these requirements and are suitable for implementation and deployment. "NSDB Protocol for Federated Filesystems", Daniel Ellard, Craig Everhart, James Lentini, Renu Tewari, Manoj Naik, 26-Sep-08, This document describes a file system federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers and collections of fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. Individual Submissions (none) ----------------------------- "Salted Challenge Response Authentication Mechanism (SCRAM)", Abhijit Menon-Sen, Chris Newman, 13-Jul-08, The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use. This specification describes 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. "Cisco Systems' Simple Certificate Enrollment Protocol", Xiaoyi Liu, 26-Jun-08, This document specifies the Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment protocol developed by Verisign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and CA implementations. "A Protocol for Remotely Managing Sieve Scripts", Alexey Melnikov, Tim Martin, 13-Sep-08, Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. "LDAP Administrators Address Attribute", Mark Wahl, 6-Sep-07, Organizations with multiple or outsourced directory servers need the ability for administrators to determine who is responsible for a particular directory server. This document defines an attribute with contact information for a directory server's responsible party, conceptually similar to the 'sysContact' object of SNMP, which can be retrieved from the directory server using the Lightweight Directory Access Protocol. "Secure Internet Live Conferencing (SILC), Protocol Specification", Pekka Riikonen, 23-Jan-07, This memo describes a Secure Internet Live Conferencing (SILC) protocol which provides secure conferencing services over insecure network channel. SILC provides advanced and feature rich conferencing services with security as main design principal. Strong cryptographic methods are used to protect SILC packets inside the SILC network. Three other specifications relates very closely to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication Protocols [SILC3] and SILC Commands [SILC4]. "SILC Packet Protocol", Pekka Riikonen, 19-Jan-07, This memo describes a Packet Protocol used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. This protocol describes the packet types and packet payloads which defines the contents of the packets. The protocol provides secure binary packet protocol that assures that the contents of the packets are secured and authenticated. "SILC Key Exchange and Authentication Protocols", Pekka Riikonen, 19-Jan-07, This memo describes two protocols used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange (SKE) protocol provides secure key exchange between two parties resulting into shared secret key material. The protocol is based on Diffie-Hellman key exchange algorithm and its functionality is derived from several key exchange protocols. The second protocol, SILC Connection Authentication protocol provides user level authentication used when creating connections in SILC network. The protocol supports passphrase (pre-shared secret) authentication and public key (and certificate) authentication based on digital signatures. "LDAP Transactions", Kurt Zeilenga, 14-Jul-08, Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions. "Multicast in MPLS/BGP IP VPNs", Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 3-Jul-08, This draft describes the deployed MVPN (Multicast in BGP/MPLS IP VPNs) solution of Cisco Systems. "The ARK Persistent Identifier Scheme", John Kunze, Richard Rodgers, 22-May-08, The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. A founding principle of the ARK is that persistence is purely a matter of service and is neither inherent in an object nor conferred on it by a particular naming syntax. The best that an identifier can do is to lead users to the services that support robust reference. The term ARK itself refers both to the scheme and to any single identifier that conforms to it. An ARK has five components: [http://NMAH/]ark:/NAAN/Name[Qualifier] an optional and mutable Name Mapping Authority Hostport (usually a hostname), the "ark:" label, the Name Assigning Authority Number (NAAN), the assigned Name, and an optional and possibly mutable Qualifier supported by the NMA. The NAAN and Name together form the immutable persistent identifier for the object independent of the URL hostname. An ARK is a special kind of URL that connects users to three things: the named object, its metadata, and the provider's promise about its persistence. When entered into the location field of a Web browser, the ARK leads the user to the named object. That same ARK, inflected by appending a single question mark (`?'), returns a brief metadata record that is both human- and machine- readable. When the ARK is inflected by appending dual question marks (`??'), the returned metadata contains a commitment statement from the current provider. Tools exist for minting, binding, and resolving ARKs. "SILC Commands", Pekka Riikonen, 19-Jan-07, This memo describes the commands used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Commands are very important part of the SILC protocol. Usually the commands are used by SILC clients to manage the SILC session, but also SILC servers may use the commands. This memo specifies detailed command messages and command reply messages. "Multicast DNS", Stuart Cheshire, Marc Krochmal, 11-Sep-08, As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server, is becoming essential. Multicast DNS (mDNS) provides the ability to do DNS-like operations on the local link in the absence of any conventional unicast DNS server. In addition, mDNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of mDNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. "Requirements for Replacing AppleTalk", Stuart Cheshire, Marc Krochmal, 11-Sep-08, One of the important goals of the participants working on Zeroconf, Multicast DNS, and DNS-Based Service Discovery was the desire to retire AppleTalk and the AppleTalk Name Binding Protocol, and to replace them with an all-IP solution. This document outlines the specific requirements that IP-based protocol(s) need to meet to make that possible. "Compressed Data within an Internet EDI Message", Terry Harding, 27-Aug-08, This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. "URI Scheme for GSM Short Message Service", Erik Wilde, Antti Vaha-Sipila, 4-Sep-08, This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. "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", Elwyn Davies, Avri Doria, 8-Aug-08, This document analyses the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "A Set of Possible Requirements for a Future Routing Architecture" [I-D.irtf-routing-reqs], which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical concensus of the research group at the date of publication. [Note to RFC Editor: Please replace the reference in the abstract with a non-reference quoting the RFC number of the companion document when it is allocated, i.e., '(RFC xxxx)' and remove this note.] "IMAP METADATA Extension", Cyrus Daboo, 13-Jul-08, The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "meta data" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. "Web Distributed Authoring and Versioning (WebDAV) SEARCH", Julian Reschke, Surendra Reddy, Jim Davis, Alan Babich, 30-Aug-08, This document specifies a set of methods, headers and properties 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.Editorial Note (To be removed by RFC Editor before publication) Please send comments to the Distributed Authoring and Versioning (WebDAV) DASL mailing list at , which may be joined by sending a message with subject "subscribe" to . Discussions of the WebDAV DASL mailing list are archived at . An issues list and XML and HTML versions of this draft are available from . "An IPv4 Flowlabel Option", Thomas Dreibholz, 11-Jul-08, This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. "SILC Message Flag Payloads", Pekka Riikonen, 26-May-05, This memo describes the data payloads associated with the SILC Message Flags, as defined in the SILC Packet Protocol specification [SILC2]. The purpose of the Message Flags is to augment the function of the Message Payload used to send both private and channel messages, by allowing the sender to tell the receiver what type of data the payload includes, and how the data should be processed. Some of the Message Flags may define additional payloads to be associated with the flag, and this memo describes these payloads. "User Online Presence and Information Attributes", Pekka Riikonen, 19-Jan-07, This document defines set of attributes that can represent the online user's presence in a network, and to provide general information about the user. The purpose is to provide a generic mechanism to share online presence and status, and general information about the user to be used in several kind of network protocols and applications. These attributes could be used by for example chat and conferencing protocols (such as Instant Message protocols), network games, and other similar network protocols and applications that has online users in a network. "Advertisement of Multiple Paths in BGP", Daniel Walton, 14-Jul-08, In this document we propose a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. "Using PPP-over-Ethernet (PPPoE) in Wireless LANs", Giuseppe Paterno, 26-May-05, This document explores the use of Point-To-Point Protocol over Ethernet (PPPoE) to provide wireless access to the Internet and suggests how the infrastructure can be deployed. The document targets consumers, corporations, Internet Service Providers, and mobile phone operators that provide user access through Wireless LANs technologies such as IEEE 802.11. "EAP-Support in Smartcard", Guy Pujolle, Pascal Urien, 4-Aug-08, This document describes the functional interface, based on the ISO7816 standard, to EAP methods, fully and securely executed in smart cards. This class of tamper resistant device may deliver client or server services; it can compute Root Keys from an Extended Master Session Key (EMSK). "Guidelines for Specifying the Use of IPsec Version 2", Steven Bellovin, 3-Aug-08, The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. "Split Multi-link Trunking (SMLT)", Roger Lapuh, Dinesh Mohan, Richard Mcgovern, 8-Jul-08, This document describes Split Multi-link Trunking (SMLT) for bridged and routed networks. SMLT enables topologies with upstream node redundancy for increased reliability of Layer 2 link aggregationsubnetworks based on [IEEE 802.3ad] and router redundancy based on VRRP [RFC3768]. SMLT is an improvement over Multi-Link Trunking (MLT), a method of link aggregation that allows multiple Ethernet links to be aggregated together, and handled as a single logical trunk. MLT can be realized via many different link aggregation mechanisms. Several methods of MLT are in use today; one example is [IEEE 802.3ad]. SMLT is MLT with links of a link-aggregation group connected to ports on two different devices (e.g. SMLT client and aggregation device). Unlike MLT, at least one end of a link-aggregated group is dual-homed to two different SMLT aggregation devices. In many cases those devices act as bridges (switches) as well as L3 routers (Routing Switches). These two redundant SMLT aggregation devices can share one or more VRRP routing instances; for that SMLT-VRRP extends the VRRP functionality to an active-active router concept, where both SMLT aggregation device route traffic for a common VRRP-ID, thus load balancing traffic not only for L2 but also for L3. "DNS-Based Service Discovery", Stuart Cheshire, Marc Krochmal, 11-Sep-08, This document describes a convention for naming and structuring DNS resource records. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this convention allows clients to discover a list of named instances of that desired service, using standard DNS queries. In short, this is referred to as DNS-based Service Discovery, or DNS-SD. "Reliable Server Pooling Applicability for IP Flow Information Exchange", Thomas Dreibholz, Lode Coene, Phillip Conrad, 11-Jul-08, This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol. "Early Retransmit for TCP and SCTP", Mark Allman, 25-Jun-08, This document proposes a new mechanism for TCP and SCTP that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover packet losses that would otherwise require a lengthy retransmission timeout. "The LDAP No-Op Control", Kurt Zeilenga, 14-Jul-08, This document defines the Lightweight Directory Access Protocol (LDAP) No-Op control which can be used to disable the normal effect of an operation. The control can be used to discover how a server might react to a particular update request without updating the directory. "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis, 14-Jul-08, This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events. "Lumas - Language for Universal Message Abstraction and Specification", Peter Cordell, 2-Feb-07, A number of methods and tools are available for defining the format of messages used for application protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary complexity and verbosity both in the definition and on the wire. Lumas - Language for Universal Message Abstraction and Specification - has been custom designed for the purpose of message definition. It is thus easy to specify messages in a compact, extensible format that is readily machine manipulated to produce a compact encoding on the wire. "A Set of Possible Requirements for a Future Routing Architecture", Avri Doria, Elwyn Davies, Frank Kastenholz, 15-Jun-08, The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group in 2001, with some editorial updates up to 2006. The two sub-groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. "Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment", Sanjib HomChaudhuri, Marco Foschiano, 19-Aug-08, This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead. Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the- home basement networks) are mentioned in the following to exemplify its possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. "A Bound End-to-End Tunnel (BEET) mode for ESP", Pekka Nikander, Jan Melen, 5-Aug-08, This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. "Example call flows using SIP security mechanisms", Cullen Jennings, Kumiko Ono, 7-Jul-08, This document shows call flows demonstrating the use of SIPS, TLS, and S/MIME in SIP. This draft provides information that helps implementers build interoperable SIP software. It is purely informational. To help facilitate interoperability testing, it includes certificates used in the example call flows and a CA certificate to create certificates for testing. This work is being discussed on the sip@ietf.org mailing list. "SixXS Heartbeat Protocol", Jeroen Massar, 6-Jun-05, This document proposes a heartbeat protocol for signalling availability of hosts with a specific emphasis on providing a signalling protocol for allowing dynamic non-24/7 endnodes to use tunnel's of the various IPv6 Tunnel Brokers. "Mixmaster Protocol Version 2", U Moeller, 30-Dec-04, Most e-mail security protocols only protect the message body, leaving useful information such as the identities of the conversing parties, sizes of messages and frequency of message exchange open to adversaries. This document describes Mixmaster version 2, a mail transfer protocol designed to protect electronic mail against traffic analysis. "Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication", Hannes Tschofenig, Alper Yegin, Dan Forsberg, 14-Jul-08, The DHCP authentication extension (RFC 3118) cannot be widely deployed due to lack of a key agreement protocol. This document outlines how EAP-based network access authentication mechanisms can be used to establish bootstrap keying material that can be used to subsequently use RFC 3118 security. "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", Marc Blanchet, Florent Parent, 6-May-08, A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6 or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP protocol within the model of the tunnel broker model. "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Cornelia Kappler, Xiaoming Fu, Bernd Schloer, 21-Aug-08, This document describes a QoS Model to signal IntServ controlled load service with QoS NSLP. QoS NSLP is QoS Model agnostic. All QoS Model specific information is carried in an opaque object, the QSPEC. This document hence specifies the QSPEC for controlled load service, how the QSPEC must be processed in QoS NSLP nodes, and how QoS NSLP messages must be used. "DNS Blacklists and Whitelists", John Levine, 10-Oct-08, The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become a de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS based blacklists and whitelists, and the protocol used to query them. IRTF Notice This document is a product of the Anti-Spam Research Group (ASRG). Comments and discussion may be directed to the ASRG mailing list, asrg@irtf.org. This document represents the consensus of the Anti-Spam Research Group of the Internet Research Task Force. "Guidelines for Management of DNSBLs for Email", Chris Lewis, Matt Sergeant, 28-Jul-08, The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists ("DNSBLs") of IP addresses or domain names intended to help guide email filtering. This memo discusses guidelines for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam. The document will seek BCP status. Comments and discussion of this document should be addressed to the asrg@ietf.org mailing list. "Light Weight Access Point Protocol", Pat Calhoun, 2-Mar-07, In the recent years, there has been a shift in wireless LAN product architectures from autonomous access points to centralized control of light weight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility and radio management out of the access point into a centralized controller. The IETF's CAPWAP WG has identified that a standards based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Light Weight Access Points). This specification defines the Light Weight Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol, and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. "Nested Nemo Tree Discovery", Pascal Thubert, Caroline Bontoux, Nicolas Montavont, Ben McCarthy, 1-Aug-08, This paper describes a simple distance vector protocol that exposes only a default route towards the infrastructure in a nested NEMO configuration. The draft extends the Neighbor Discovery Protocol [1] in order to carry information and metrics which will help a Mobile Router select its Attachment Router(s) in an autonomous fashion and provides generic rules which guarantee that the interaction of different selection processes will not create loops. "Internet Mail Architecture", Dave Crocker, 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. "IP Fast Reroute using tunnels", Stewart Bryant, Clarence Filsfils, Stefano Previdi, Mike Shand, 16-Nov-07, This draft describes an IP fast re-route mechanism that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, the identity of all the unprotected links and routers is known in advance. This IP Fast Reroute advanced method was invented in 2002 and draft (draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to the IETF in May 2004. It was one of the first methods of achieving full repair coverage in an IP Network, and as such the draft has been widely referenced in the academic literature. The authors DO NOT propose that this IPFRR method be implemented since better IPFRR advanced method capable of achieving full repair coverage have subsequently been invented. "DISCOVER: Supporting Multicast DNS Queries", Bill Manning, Paul Vixie, 17-Nov-05, This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result. "RADIUS Attributes for the Delivery of Keying Material", Glen Zorn, 17-Apr-07, This document defines a set of RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. "Extending the Space Available for TCP Options", Wesley Eddy, Adam Langley, 1-Jul-08, This document describes a method for increasing the space available for TCP options. Two new TCP options (LO and SLO) are detailed which reduce the limitations imposed by the TCP header's Data Offset field. The LO option provides this extension after connection establishment, and the SLO option aids in transmission of lengthy connection initialization and configuration options. "TLS Express", Mohamad Badra, 16-Feb-05, This document defines a new extension that may be used to add Pre Shared Key authentication functionality to TLS. It is based on the TLS abbreviated handshake and it provides the ability to share a session key for data encryption. "IPv6 Label Switching Architecture", Sham Chakravorty, Jeff Bush, Jim Bound, 9-Jul-08, This specification provides an architectural framework, called IPv6 Label Switching Architecture or 6LSA, for an end-to-end, IP-centric packet transmission technique that uses the IPv6 packet header Flow Label to establish IPv6-based label switched paths. The label switched paths, called 6LSPs, provide application and user specified routes for efficient transport of packets and as means for quality of service (QoS) delivery, IPv4 tunneling, VPN and other mechanisms. Through look-ups of 20-bit labels instead of 128-bit IPv6 addresses, the architecture may provide potential memory and processing savings, the latter through significantly reduced address fetches for the low- powered, handheld devices. The label has two components comprising Global Label value and Local Label value. The Global Label value from the source is delivered to the destination unmodified. However, the intermediate network nodes in 6LSA are allowed to temporarily replace the Local Label value with a value of local significance. This enables 6LSA flows to be hop-specific although session-based and as such a unique QoS delivery technique for bandwidth constrained media. 6LSA also enhances security since label generation and assignment algorithms can be modified periodically. Finally, it must be pointed out that the 6LSA concept of temporary flow label assignment is applicable to the 6LSA domain only. The concept is not applicable to domains outside the 6LSA. "SDP Descriptors for FLUTE", Harsh Mehta, 30-Jan-06, This document specifies the use of SDP to describe the parameters required to begin, join, receive data from, and/or end FLUTE sessions. It also provides a Composite Session SDP media grouping semantic for grouping media streams into protocol-specific sessions, such as multiple-channel FLUTE sessions. "Scope Modifiers in Intellectual Property Declarations", I Maturana, I Robredo, 16-Aug-05, The purpose of this RFC is to focus discussion on intellectual property problems in the Internet. This document introduces and defines scope modifiers to be used in intellectual property declarations. These modifiers abstract the ownership behavior of resources available in interoperable environnments, such as the Internet. "The IPvLX Architecture", Fred Templin, 11-May-07, The IETF has embraced IPv6 as the next-generation Internet protocol, but global IPv4 deployment continues in private addressing domains behind Network Address Translators (NATs). This document envisions a long-term IPv6/IPv4 coexistence, with IPv6 addresses serving as identifiers (and sometimes also locators) and IPv4 addresses serving as locators (and sometimes also identifiers). This document proposes an architectural framework for IPv6/IPv4 coexistence called: "IPvLX (IP with virtual Link Extension)". "Atomsub: Transporting Atom Notifications over the Publish-Subscribe Extension to the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, Joe Hildebrand, Bob Wyman, 7-May-08, This memo describes a method for notifying interested parties about changes in syndicated information encapsulated in the Atom feed format, where such notifications are delivered via an extension to the Extensible Messaging and Presence Protocol (XMPP) for publish- subscribe functionality. "Message Header Field for Indicating Message Authentication Status", Murray Kucherawy, 23-Sep-08, This memo defines a new message header field for use with electronic mail messages to indicate the results of message authentication efforts. Mail user agents (MUAs) may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. "HIP Experiment Report", Tom Henderson, Andrei Gurtov, 14-Jul-08, This document is a report from the IRTF HIP research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The documents summarizes implications of HIP to host protocol stack, Internet infrastructure, and applications. The perspective of the network operator, as well as a list of HIP experiments are presented as well. "Common Intrusion Detection Signatures Standard", Adam Wierzbicki, Jacek Kalinski, Tomasz Kruszona, 4-Sep-08, The purpose of the Common Intrusion Detection Signatures Standard (CIDSS) is to define a common data format for storing signatures from different intrusion detection systems. This Internet-Draft describes a common data format to represent information contained in signatures of intrusion detection systems, and explains the rationale for using this common format. The proposed format is a dialect of the Extensible Markup Language (XML). An XML Document Type Definition is developed, and examples are provided. "Network-Layer Signaling: Transport Layer", Melinda Shore, David McGrew, Kaushik Biswas, 13-Jul-08, The RSVP model for communicating requests to network devices along a datapath has proven useful for a variety of applications beyond what the protocol designers envisioned, and while the architectural model generalizes well the protocol itself has a number of features that limit its applicability to applications other than IntServ. Network Layer Signaling uses the RSVP on-path communication model and provides a lightweight transport layer for non-QoS signaling applications, such as discovery or diagnostics. It is based on a "two-layer" architecture that divides protocol function into transport and application. This document describes the transport protocol. "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", Joseph Touch, 8-Jul-08, This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It updates the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version is intended as an update to RFC3285. The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools "Bounding Longer Routes to Remove TE", Susan Hares, 31-Jul-08, Some ASes currently use length-based filters to manage the size of the routing table they use and propagate. This draft explores an alternative to length-based filters which allows for more automatic configuration and which provides for better redundancy. Rather than use a filter, this draft proposes a method of modifying the BGP [RFC1771] longest match algorithm by setting a bound on the prefix lengths eligible for preference. A bound would operate on long prefixes when covering route announcements are available; in certain circumstances it would cause a router to prefer an aggregate over a more specific route announcement. "The "OpenPGP" mail and news header field", Atom Smasher, Simon Josefsson, 20-May-08, This document describes the "OpenPGP" mail and news header field. The field provide information about the sender's OpenPGP key. See for more information. "Care-of Address Test for MIPv6 using a State Cookie", Francis Dupont, Jean-Michel Combes, 2-Jun-08, This document defines a procedure which performs a "care-of address test" using a state cookie for routing optimization in Mobile IPv6 not protected by the routing routability procedure, i.e., protected by some alternative mechanisms like pre-shared secret or pre- established IPsec security associations. "Certificate Exchange Messaging for EDIINT", Kyle Meadors, Dale Moberg, 14-Jul-08, The EDIINT AS1, AS2 and AS3 message formats do not currently contain any neutral provisions for transporting and exchanging trading partner profiles or digital certificates. EDIINT Certificate Exchange Messaging provides the format and means to effectively exchange certificates for use within trading partner relationships. The messaging consists of two types of messages, Request and Response, which allow trading partners to communicate certificates, their intended usage and their acceptance through XML. Certificates can be specified for use in digital signatures, data encryption or SSL/TLS over HTTP (HTTPS). "IPFIX Flow Aggregation", Falko Dressler, Christoph Sommer, Gerhard Muenz, Atsushi Kobayashi, 14-Jul-08, IPFIX Flow Aggregation describes a methodology for reducing the amount of measurement data exchanged between monitoring devices (IPFIX Exporters) and analyzers (IPFIX Collectors). Aggregation techniques represent a necessary enhancement in order to cope with increasing amounts of monitoring data that accrue with the ever- growing network capacities. Using Flow Selection Criteria and Compound Flow creation techniques, measurement information of multiple Flows that are sharing some common criteria is merged to be exported in one Compound Flow. Subsets of Flows eligible for aggregation, as well as the desired degree of similarity, can be customized using a set of Aggregation Rules. "VoIP Configuration Server Address Option", Richard Johnson, 8-Jul-08, This memo documents existing usage for the "VoIP Configuration Server Address Option" (previously known as the "TFTP Server IP Address Option"). The option number currently in use is 150. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. "Circuit Cross-Connect", Kireeti Kompella, 9-Feb-06, Circuit Cross-Connect (CCC) was the ground-breaking design and implementation of the transport of Layer 2 frames over Multi-Protocol Label Switching (MPLS), which is now seen as an important application of MPLS. Thus, documenting CCC is important from a historical point of view. Furthermore, CCC is still in production in many networks, providing yet another reason to document it. It is hoped that those interested in this area will see where it started, how far we have come, and the strengths and weaknesses of this particular approach, and thereby gain some perspective of the area. If in the process they get new insights for the future development in this area, that is a bonus. "Transmitting Confidential Data in RADIUS", Glen Zorn, Hao Zhou, Joseph Salowey, 29-Aug-08, This document defines a set of Type-Length-Value (TLV) tuples which, when encapsulated in RADIUS Extended Attributes, are designed to allow the secure transmission of sensitive or confidential data (including encryption keys) between RADIUS clients and servers. "The LDAP Don't Use Copy Control", Kurt Zeilenga, 13-Jul-08, This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. "Session Initiation Protocol (SIP) Session Mobility", Ron Shacham, Henning Schulzrinne, Srisakul Thakolsri, Wolfgang Kellerer, 18-Nov-07, Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP). Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is intended as an informational document. "SDP and RTSP extensions defined for 3GPP Packet-switched Streaming Service and Multimedia Broadcast/Multicast Service", Magnus Westerlund, Per Frojdh, 7-Jul-08, The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP and RTSP with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. "P3P Policy Attributes for LDAP", Mark Wahl, 12-Dec-06, This document defines attributes for use in the Lightweight Directory Access Protocol (LDAP) which contain URIs for privacy policy documents. These documents describe the privacy policy concerning access to a directory server, and the privacy policies that apply to the contents of the directory (a subtree of entries). "Wireless LAN Control Protocol (WiCoP)", Satoshi Iino, 7-Feb-07, The popularity of wireless local area networks (WLANs) has led to wide spread deployments across different establishments. It has also translated in to increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common. The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the control and provisioning of wireless access points (CAPWAP). "Multiple Attachments for EDI-INT", Kyle Meadors, 16-Jun-08, The EDIINT AS1, AS2 and AS3 message were designed specifically for the transport of EDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDI-INT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This informational draft describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDI-INT transport message. The attachments are stored within the MIME Multipart/Related structure. A minimal list of content-types to be supported as attachments is provided. "Best Current Practices of XCAST (Explicit Multi-Unicast) by 2004", Chih-Chang Hsu, 22-Jul-05, In 2000, XCAST (Explicit Multi-Unicast) was first proposed as a protocol intended for small group multicasting. It combined three similar datagram simulcasting protocols that were submitted as earlier Internet Drafts by a number of different research groups. After that, researchers in those groups worked together to further develop, experiment and conduct standardization in IETF as well as in the open source community. This resulted in several implementations of protocol stacks, systems of multi-party video conference and group management, and mechanisms for harmonizing XCAST with ASM and SSM. In addition, an XCAST backbone for various experiments has been launched to operate inter-continentally. One of the main purposes of this document is to summarize the efforts undertaken by XCAST community as "best current practices" that would then be formally introduced to the IETF/IRTF community. In addition, we raise an issue concerning IANA resource allocation, which prevents us from widely expanding our experimental networks as well as distributing our software. Finally, we request IESG and other experts to check the validity of our proposed protocol and make any suggestions about how IANA can assign appropriate resources accordingly. "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. "An Extensible Format for Email Feedback Reports", Yakov Shafranovich, John Levine, Paul Hoffman, Murray Kucherawy, 16-Jun-08, This document defines an extensible format and MIME type that may be used by network operators to report feedback about received email to other parties. This format is intended as a machine readable replacement for various existing report formats currently used in Internet email. "Registration Templates for Legacy Message Header Field Names", Bruce Lilly, 21-Apr-05, This memo documents several Internet Message Format message header field names and provides registration templates so that the names can be registered in the permanent message header field name registry. "Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, Irene Ruengeler, 14-Jul-08, Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind 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 and multi-point traversal scenario. "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, 19-Sep-08, This document defines extensions to the CalDAV "calendar-access" feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. "Distributing Address Selection Policy using DHCPv6", Tomohiro Fujisaki, Arifumi Matsumoto, Shirou Niinobe, Ruri Hiromi, Ken-ichi Kanayama, 3-Jun-08, This document describes a new DHCPv6 option for distributing address selection policy information defined in RFC3484 to a client. With this option, site administrators can distribute address selection policy to control the node's address selection behavior. "Applicability of Loop-free Convergence", Stewart Bryant, Mike Shand, 28-May-08, This draft describes the applicability of loop free convergence technologies to a number of network applications. "NAT Port Mapping Protocol (NAT-PMP)", Stuart Cheshire, 16-Apr-08, This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IP address of a NAT gateway, thus allowing a client to make this external IP address and port number known to peers that may wish to communicate with it. This protocol is implemented in current Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. "Using non-ASCII Characters in RFCs", Tim Bray, Paul Hoffman, 6-Oct-08, This document specifies a change to the IETF process in which Internet Drafts and RFCs are allowed to contain non-ASCII characters. The proposed change is to change the encoding of Internet Drafts and RFCs to UTF-8. "Security Extension for Unidirectional Lightweight Encapsulation Protocol", Prashant Pillai, 14-Jul-08, This document describes the header extension for Unidirectional Encapsulation Protocol (ULE) that secures the IP traffic transported using ULE to provide security features like data confidentiality, data integrity, data origin authentication and mechanisms to prevent replay attacks. The format of the header extension and processing at the Receiver and Transmitter are described in detail. "QoS-Enhanced Border Gateway Protocol", Mohammed Boucadair, 5-Jul-05, This memo describes a proposal for exchanging QoS-enabled reachability information between service providers. It defines new BGP attributes to be used in order to convey QoS performance characteristics between service providers and it describes how to use these QoS values in order to select the best path. An example of route selection process that takes into account the QoS performance values enclosed in BGP messages is also detailed. "The Meta-QoS-Class concept", Pierre Levis, Mohammed Boucadair, 30-Jun-05, This document describes a framework for inter-domain Quality of Service (QoS). It makes use of a new concept denoted by Meta-QoS- Class. This new concept guides and simplifies QoS agreements between providers and opens up new perspectives for a global QoS-enabled Internet. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 11-Jul-08, This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. "RADIUS Attributes for IEEE 802 Networks", Bernard Aboba, Jouni Malinen, Paul Congdon, Joseph Salowey, 2-Jun-08, RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks. The attributes defined in this document are usable both within RADIUS and Diameter. "Use of the Reason header filed in Session Initiation Protocol (SIP) responses", Roland Jesske, Martin Huelsemann, 7-Oct-08, This document proposes the use of the Reason header field in SIP responses. "Distributed Multimodal Synchronization Protocol", Jonathan Engelsma, Chris Cross, 31-Jul-07, This document proposes a Distributed Multimodal Synchronization Protocol (DMSP) designed to enable multimodal interaction for mobile devices by accessing services in the network. More specifically, this protocol coordinates events of interest between a visual browser or application running on a mobile device with a VoiceXML (Voice Extensible Markup Language) browser running in the network. "Dynamic Provisioning using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", Nancy Cam-Winget, David McGrew, Joseph Salowey, Hao Zhou, 30-Jul-08, The flexible authentication via secure tunneling EAP method (EAP- FAST) enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP-FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning. "Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz, 11-Jul-08, This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC2960, it is designed to integrate cryptographic functions into SCTP. "General Area Review Team (GenART) Experiences", Mary Barnes, Avri Doria, Harald Alvestrand, Brian Carpenter, 14-Aug-08, The General Area Review team has been doing Reviews of Internet Drafts since 2004. This draft discusses the experience and the lessons learned over the past 4+ years of this process. The review team initially did reviews before each of the IESG telechats. Beginning in late 2005, review team members have been assigned to review documents during IETF Last Call, unless no IETF Last Call is necessary for the document. The same reviewer then reviews any updates when the document is placed on an IESG telechat agenda. "Combined Presence Schemas Utilizing RELAX NG", Jari Urpalainen, 9-Oct-08, This memo describes a batch of Presence Information Data Format (PIDF) and its extension schemas written with the RELAX NG schema language. Unlike with the current W3C XML Schema language it is possible to write reasonable forwards and backwards compatible presence combination schemas. These RELAX NG schemas are stricter than the W3C Schemas and thus the instance documents that validate with these schemas follow the intended content model more closely. Especially, these schemas are targeted to actual implementations in order to decrease interoperability problems. "Operational Reliability for EDIINT AS2 draft-duker-as2-reliability-04.txt", Intellectual Property, 4-Sep-08, The goal of this document is to define approaches to achieve a "once and only once" delivery of messages. The EDIINT AS2 protocol [AS2] is implemented by a number of software tools on a variety of platforms with varying capabilities and with varying network service quality. Although the AS2 protocol defines a unique "Message-ID", current implementations of AS2 do not provide a standard method to prevent the same message (re-transmitted by the initial sender) from reaching back-end business applications at the initial receiver. TCP underpinnings of HTTP over which AS2 operates generally provide a good quality of network connectivity, but experience indicates a need to be able to compensate for both transient server and socket exceptions, including "Connection refused" as well as "Server busy." In addition, difficulties with server availability, stability, and loads can result in reduced operational reliability. This document describes some ways to compensate for exceptions and enhance the reliability of AS2 protocol operation. Implementation of these reliability features is indicated by presence of the "AS2- Reliability" value in the EDIINT-Features header. "Link Adaptation for IPv6-in-(foo)*-in-IPv4 Tunnels", Fred Templin, 14-May-07, IPv6-in-(foo)*-in-IPv4 tunnels must support a minimum Maximum Transmission Unit (MTU) of 1280 bytes for IPv6 via static prearrangements and/or dynamic MTU determination based on ICMPv4 messages, but these methods have known operational limitations. This document specifies a link adaptation mechanism for IPv6-in-(foo)*-in- IPv4 tunnels that presents an assured MTU to the IPv6 layer using tunnel endpoint-based segmentation/reassembly and dynamic segment size probing. "EDI-INT Features Header", Kyle Meadors, 1-Oct-08, With the maturity of the EDI-INT standard of AS1, AS2 and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDI-INT applications and could cause potential problems with implementations. "HIP DHT Interface", Jeff Ahrenholz, 7-Oct-08, This document specifies a common interface for using HIP with a Distributed Hash Table service to provide a HIT-to-address lookup service and an unmanaged name-to-HIT lookup service. "MTLS: TLS Multiplexing", Mohamad Badra, Ibrahim Hajjeh, 19-May-08, 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, an application-level 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. "Password-Authenticated Diffie-Hellman Exchange (PAK)", Igor Faynberg, Zachary Zeltsan, Alec Brusilovsky, 9-Oct-08, This document proposes to add mutual authentication, based on human-memorizable password, to the basic unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called Password-authenticated Key exchange (PAK). PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange. The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attackers to obtain any information that would enable an off-line dictionary attack on the password. The use of Diffie-Hellman exchange ensures Forward Secrecy. "Moving Forwards with IETF Process Evolution", Elwyn Davies, 26-Oct-06, This document provides a summary of previously identified problems with the Internet Engineering Task Force (IETF) process for developing standards and other specifications; and then identifies a set of goals to aim at, and guidelines that should be followed during any activity seeking to revise and update this process. It does not propose specific changes to the process, which should be the subject of future documents. "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", Keith Drage, 14-Jul-08, This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses.1. Overall Applicability The SIP extensions specified in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions are generally NOT APPLICABLE in the Internet as a whole. The mechanisms specified here were designed to satisfy the requirements specified in the 3GPP Release 5 requirements on SIP [RFC4083] for which either no general-purpose solution was planned, where insufficient operational experience was available to understand if a general solution is needed, or where a more general solution is not yet mature. For more details about the assumptions made about these extensions, consult the Applicability subsection for each extension.2. Conventions "Privacy Aspects Terminology", Wassim Haddad, Erik Nordmark, 25-Jun-08, This memo introduces terminology for the main privacy aspects. The prime goal is to avoid situations where different interpretations of the same key privacy aspects result in different requirements when designing specific solutions, thus leading to an unnecessary confusion. "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob Briscoe, Arnaud Jacquet, T Moncaster, Alan Smith, 4-Aug-08, This document introduces a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. It enbales the the upstream party at any trust boundary in the internetwork to be held responsible for the congestion they cause, or allow to be caused. So, networks can introduce straightforward accountability for congestion and policing mechanisms for incoming traffic from end- customers or from neighbouring network domains. The protocol works by arranging an extended ECN field in each packet so that, as it crosses any interface in an internetwork, it will carry a truthful prediction of congestion on the remainder of its path. The purpose of this document is to specify the re-ECN protocol at the IP layer and to give guidelines on any consequent changes required to transport protocols. It includes the changes required to TCP both as an example and as a specification. It also gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion. And it describes example mechanisms that ensure the dominant selfish strategy of both network domains and end- points will be to set the extended ECN field honestly. "Considerations for Having a Successful BOF", Thomas Narten, 12-Oct-07, This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) Session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. "Carrying Attached Addresses in IS-IS", David Ward, Radia Perlman, Russ White, Dino Farinacci, Ayan Banerjee, 22-May-08, This draft specifies the IS-IS extensions necessary to support multi- link IPv4 and IPv6 networks, as well as to provide true link state routing to any protocols running directly over layer 2. While supporting this concept involves several pieces, this document only describes extensions to IS-IS. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used.1. Overview There are a number of systems (for example, [RBRIDGES]) which have proposed using layer 2 addresses carried in a link state routing protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer 2 routing in specific environments. This draft proposes a set of TLVs and sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new PDU types, to support these proposed systems. This draft does not propose new forwarding mechanisms using this additional information carried within IS-IS. There is a short section included on two possible ways to build a shortest path first tree including this information, to illustrate how this information might be used. "IAX: Inter-Asterisk eXchange Version 2", Mark Spencer, Brian Capouch, Ed Guy, Frank Miller, Kenneth Shumard, 5-Oct-08, This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding which decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload types additions needed to support additional services. "Operational issues with Tiny Fragments in IPv6", Vishwas Manral, 9-Sep-08, IPv6 fragmentation allows fragments to be sent only by the source of a packet. The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. Firewalls generally use 5-tuples to filter out packets. However there are cases where fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document specifies where tiny fragments can be issues. "The Atom "deleted-entry" Element", James Snell, 21-Apr-08, This specification adds mechanisms to the Atom Syndication Format which Atom Feed publishers can use to explicitly identify Atom entries that 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, 28-Jul-08, 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. "Key Management through Key Continuity (KCM)", Peter Gutmann, 29-Sep-08, This memo provides advice and Best Current Practice for implementors and deployers of security applications that wish to use the key continuity method of key management. "Private Extensions to the Session Initiation Protocol (SIP) for Service Interaction Indicator", Yuzhong Shen, 28-May-08, In SIP-based networks, a SIP session MAY involve several application servers on the originating and terminating side. In a certain case, an application server needs to set some indications in SIP message to indicate service information (what are invoked, what can be allowed and what should blocked). This kind of information will be also required for composition of SIP applications. There is a need to provide indicators for service interaction between SIP application servers or other SIP endpoints. This document describes a mechanism of service interaction indicator for the Session Initiation Protocol (SIP) that enhances service interaction between SIP application servers in a trusted network. "The "pack" URI Scheme", Andrey Shur, Jerry Dunietz, 7-Aug-08, A package is a logical entity that holds a collection of parts. Given the URI for a complete package, the "pack" URI scheme provides for the construction and use of URIs referring to individual parts within the package. It also provides for the use of part's URIs as base URIs for resolving relative references between the parts in a single package. "Transport Layer Security (TLS) Authorization Extensions", Mark Brown, Russ Housley, 10-Sep-07, This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information is exchanged in the supplemental data handshake message. "LowPan Neighbor Discovery Extensions", Samita Chakrabarti, Erik Nordmark, 14-Jul-08, IETF 6LowPan working group defines IPv6 over low-power personal area network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have multicast support, although it supports broadcast. Due to the nature of LowPan network or sensor networks, broadcast messages should be minimized. This document suggests some optimizations to IPv6 Neighbor Discovery related multicast messages in order to reduce signaling in the low-cost low-powered network. "BR Organization Mapping for the Extensible Provisioning Protocol (EPP)", Frederico Neves, Hugo Koji Kobayashi, 24-Aug-06, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of .br organizational social information stored in a shared central repository. Specified in XML, this mapping extends the EPP contact mapping to provide additional features required for the provisioning of .br organizational social information. "Using DNS SRV to Specify a Global File Name Space with NFS version 4", Craig Everhart, Andy Adamson, Jiaying Zhang, 8-Sep-08, The NFS version 4 protocol provides a natural way for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple and appropriate way for an organization to publish the root of its name space, even to clients that might not be intimately associated with such an organization. DNS SRV can be used to join these organization-wide file name spaces together to allow construction of a global, uniform NFS version 4 file name space. This document refreshes the draft. "WiMAX Forum/3GPP2 Proxy Mobile IPv4", Kent Leung, 4-Aug-08, Mobile IPv4 is a standard mobility protocol that enables IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2. "Media Server Markup Language (MSML)", Adnan Saleem, 14-Aug-08, The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP Media Servers. Clients can use it to define how multimedia sessions interact on a Media Server and to apply services to individuals or groups of users. MSML can be used, for example, to control Media Server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as IVR dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXML. "PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)", Seisho Yasukawa, Adrian Farrel, 12-May-08, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. "Mobile IPv6 Location Privacy Solutions", QIU Ying, Fan Zhao, Rajeev Koodli, 14-Jul-08, Mobile IPv6 (RFC 3775) enables mobile nodes to remain reachable while roaming on the Internet. However, the location of a mobile node can be revealed and its movement tracked by simply monitoring the Mobile IPv6 addresses in the IP packets. In this document, we consider the MIP6 location privacy problem described in RFC 4882 and propose efficient and secure techniques to protect the location privacy of a mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. "Organizing IETF Process Change", Elwyn Davies, 13-Jun-06, This document sets out a strawman proposal for how to organize the revision and update of any part of the Internet Engineering Task Force (IETF) processes including those for developing standards and other specifications. It does not propose specific changes to any of these processes, which should be the subject of future documents. However, it does propose an initial target area for process change. "Authorization for NSIS Signaling Layer Protocols", Jukka Manner, Martin Stiemerling, Hannes Tschofenig, Roland Bless, 2-Jul-08, Signaling layer protocols in the NSIS working group may rely on GIST to handle authorization. Still, the signaling layer protocol itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This draft presents a generic model and object formats for session authorization within the NSIS Signaling Layer Protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes. "ZRTP: Media Path Key Agreement for Secure RTP", Philip Zimmermann, Alan Johnston, Jon Callas, 28-Sep-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 a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP profiles. "Definition of an Internet Research Task Force (IRTF) Document Stream", Aaron Falk, 22-Sep-08, This memo defines the publication stream for RFCs from the Internet Research Task Force. Most documents undergoing this process will come from IRTF Research Groups and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. "DNSSEC Validator API", Abhijit Hayatnagarkar, Suresh Krishnaswamy, 27-May-08, The DNS Security Extensions (DNSSEC) provide origin authentication and integrity of DNS data. However, the current resolver Application Programming Interface (API) does not specify how a validating stub resolver should communicate detailed results of DNSSEC processing back to the application. This document describes an API between applications and a validating stub resolver that allows applications to control the DNSSEC validation process and obtain results of DNSSEC processing. "Media Playback Control Protocol Requirements", Steven Whitehead, Marie-Jose Montpetit, Xavier Marjou, Sam Ganesan, Jan Lindquist, 12-May-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. "Channel Bindings for TLS based on PRF", Simon Josefsson, 12-Aug-08, This document specify how to compute data, "channel bindings", that is cryptographically bound to a specific Transport Layer Security (TLS) session. The intention is to use this data as a name of the secure channel for the purpose of a channel binding. The channel bindings can be used by authentication protocols to avoid tunneling attacks and security layer re-use. The data is derived using the TLS Pseudo-Random Function (PRF). "Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility", Thomas Dreibholz, Jobin Pulinthanath, 11-Jul-08, This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). "Fast Initial OSPFv2 LSDB Synchronization for BMA", Mitchell Erblich, 27-Mar-06, This memo documents a feature that significantly decreases the initial LSDB synchronization time in Broadcast Multiple Access (BMA) environments. This implementation only requires a single OSPF speaker per psuedo-node to support this functionality. These changes are implicitly supported within the OSPFv2 protocol. This memo is not intended to serve as a model for any other implementation. "Limited IP Header Compression over PPP", Janusz Jurski, 8-Mar-07, The negotiation options specified in RFC 2509 defined an all-or-nothing strategy for applying header compression: peers were assumed to support compression for any combination of headers. [RFC3544] refined that strategy to make it possible to negotiate header compression for only TCP or only non-TCP packets (and also added Enhanced RTP-Compression negotiation option). The current document further refines the strategy by also making it possible to negotiate header compression for only particular combinations of headers or header types. "Reliable Server Pooling (RSerPool) Bakeoff Scoring", Thomas Dreibholz, Michael Tuexen, 11-Jul-08, This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. "MPLS Benchmarking Methodology", Aamer Akhter, Rajiv Asati, 7-Jul-08, The purpose of this draft is to describe a methodology specific to the benchmarking of MPLS forwarding devices. The scope of this benchmarking will be limited to various types of packet-forwarding and delay measurements. It builds upon the tenets set forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. "SNMP Traffic Measurements and Trace Exchange Formats", , 16-Sep-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 describes an approach to carrying 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-Aug-08, This memo proposes requirements for protocols between web browsers and relying parties at websites; these requirements also impact third parties involved in the authentication process. These requirements minimize the likelihood that criminals will be able to gain the credentials necessary to impersonate a user or be able to fraudulently convince users to disclose personal information. To meet these requirements browsers must change. Websites must never receive information such as passwords that can be used to impersonate the user to third parties. Browsers should authenticate the website to the browser as part of authenticating the user to the website. Browsers MUST flag situations when this authentication fails and flag situations when the target website is not authorized to accept the identity being offered as this is a strong indication of fraud. These requirements may serve as a basis for requirements for preventing fraud in environments other than the web. "The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)", Jani Hautakorpi, Gonzalo Camarillo, 12-Nov-07, This document specifies the Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Pust to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI-list that have embedded URI-lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI-list that caused the rejection and the individual URIs that form such a URI-list. "A Profile for Resource Certificate Repository Structure", Geoff Huston, Robert Loomans, George Michaelson, 22-Jun-08, This document defines a profile for the structure of repositories that contain X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile contains the proposed object naming scheme, the contents of repository publication points, the contents of publication point manifests and a possible internal structure of a Repository Cache that is intended to facilitate synchronization across a distributed collection of repositories and facilitate certificate path construction. "MANET Autoconfiguration using Virtual Enterprise Traversal (VET)", Fred Templin, Steven Russert, Seung Yi, 20-Aug-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 Enterprise Traversal (VET) abstraction for autoconfiguration and operation of routers in MANETs. "Diameter Routing Extensions", Tina Tsou, Victor Fajardo, Jouni Korhonen, Tolga Asveren, 29-Jul-08, This document describes two(2) extensions to the current diameter routing scheme. The first extension describes an explicit routing mechanism that MAY be employed by Diameter nodes to allow specific stateful Diameter proxies to remain in the path of all messages exchanges constituting a Diameter session. The second extension describes a realm based redirection scheme as an alternative to host based redirection described in [RFC3588]. "Modes of Operation for Camellia for Use With IPsec", Akihiro Kato, Masayuki Kanda, 5-Aug-08, This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, and Counter with CBC-MAC (CCM) mode, as an IKEv2 and Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity. "Secure Beacon: Securely Detecting a Trusted Network", Yaron Sheffer, Yoav Nir, 21-Jan-08, Remote access clients, in particular IPsec-based ones, are heavily deployed in enterprise environments. In many enterprises the security policy allows remote-access clients to switch to unprotected operation when entering the trusted network. This document specifies a method that lets a client detect this situation in a secure manner, with the help of a security gateway. We propose a minor extension to IKEv2 to achieve this goal. "The LDAP Relax Rules Control", Kurt Zeilenga, 14-Jul-08, This document defines the Lightweight Directory Access Protocol (LDAP) Relax Rules Control which allows a directory user agent (a client) to request the directory service temporarily relax enforcement of various data and service model rules. "HTTP Header Linking", Mark Nottingham, 2-Jul-08, This document clarifies the status of the Link HTTP header and attempts to consolidate link relations in a single registry. "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, Intellectual Property, 8-May-08, Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to reproduce the current PSTN behaviour. "Reporting Metrics: Different Points of View", Al Morton, Gomathi Ramachandran, Ganga Maguluri, 19-May-08, 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). "DHCP Option for LDAP Directory Services discovery", Giuseppe Paterno, 28-Sep-06, This document defines an experimental DHCP option for delivering configuration information for LDAP services. Through this option, the client receives an LDAP URL [8] of the closest available LDAP server/replica that can be used to authenticate users or look up any useful data. "Definitions for TCP Connection Metrics", Terry Brugger, 17-Aug-06, Numerous metrics, or features, have been used to describe TCP connections. These features are frequently of interest to the network intrusion detection community, and occasionally the network engineering community. While researchers may understand these terms when used by others, there are no formal definitions of these terms such that two researchers looking at the same connection will necessarily calculate the same values for all the metrics. This paper will propose a potential set of connection metrics with formal definitions of each. "Device Capability Negotiation for Device-Based Location Determination and Location Measurements in HELD", Martin Thomson, James Winterbottom, 3-Jul-08, A framework for the exchange of capabilities in HELD is described. Capabilities for enabling device-based measurements and device-based location generation are described. "Delay-Tolerant Networking Custodial Multicast Extensions", Susan Symington, 5-May-08, This document defines optional extensions to the Bundle Protocol [2] for supporting the custodial multicast delivery of bundles within a Delay-Tolerant Network (DTN). The protocol extensions described herein may be used to support custody transfer and custody-based reforwarding during the transmission of a bundle from a single source node to multiple destination nodes. "Delay-Tolerant Networking Bundle-in-Bundle Encapsulation", Susan Symington, 5-May-08, 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, 15-Sep-08, This document defines an extension block that may be used with the Bundle Protocol [2] within the context of a Delay-Tolerant Network architecture [4]. This Previous Hop Insertion Block is designed to be inserted by a forwarding node to provide information to its next- hop receiving node. This block is always removed from the bundle by the receiving node so that it's duration within the bundle lasts for exactly one hop. It provides a general insertion capability to enable any node that forwards a bundle to insert an arbitrary record (or records) of information into the bundle. While this block is defined to provide an arbitrary insertion capability, this specification also defines two specific, mandatory, information record formats for the information that may be carried in the Previous Hop Insertion block. Using these mandatory information record formats, an insertion block may be used to indicate the inserting/forwarding node's endpoint ID (EID), which may be required in some circumstances to support certain routing protocols (e.g., flood routing). This document defines the format and processing of this Previous Hop Insertion Block. "Automatic Telephone Configuration Protocol", Bernd Buxmann, Ralf Hintner, 16-Aug-06, This document is about the Automatic Telephone Configuration Protocol (ATCP). ATCP provides a framework for passing configuration information to SIP-telephones in a Voice over IP-network and to register users in the network. ATCP needs DHCP for configuring the telephones with TCP/IP-networkparameters (e.g. IP-address). "SPEERMINT Security Threats and Suggested Countermeasures", Saverio Niccolini, Eric Chen, Jan Seedorf, 14-Jul-08, This memo presents the different security threats related to SPEERMINT classifying them into threats to the Location Function, to the Signaling Function and to the Media Function. The different instances of the threats are briefly introduced inside the classification. Finally the existing security solutions in SIP and RTP/RTCP are presented to describe the countermeasures currently available for such threats. The objective of this document is to identify and enumerate the SPEERMINT-specific threat vectors in order to specify security-related requirements. Once the requirements are identified, methods and solutions how to achieve such requirements can be selected. "LDAP Subtree Data Source URI Attribute", Mark Wahl, 12-Dec-06, This document defines an attribute that enables administrative clients using the Lightweight Directory Access Protocol (LDAP) to determine the source of directory entries. "Dynamic Feature Extensions to the Presence Information Data Format Location Object (PIDF-LO)", Singh Vishal, Henning Schulzrinne, Hannes Tschofenig, 12-Jul-08, The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity. 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. "Transporting User to User Call Control Information in SIP for ISDN Interworking", Alan Johnston, Joanne McMillen, 10-Jul-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. Example use cases include an exchange between two User Agents, insertion of UUI by a proxy, modification of UUI by a proxy. An example application is in an Automatic Call Distributor (ACD) in a contact center. "IPv6 Dynamic Flow Label Switching (FLS)", Martin Beckman, 22-Mar-07, This document seeks to establish a standard for the utilization of the Class of Service Field and the us of the Flow Label Field within the IPv6 Header and establish a methodology of switching packets through routers using the first 32-bits of the IPv6 header using Flow Label Switching on packets rather than full routing of packets. Within the first 32-bits of an IPv6 header exists the requisite information to allow for the immediate “switching” on an ingress packet of a router, allowing for “Label Switching” of a native IPv6 packet. This allows the establishment of VPN circuits in a dynamic manner across transit networks. The establishment of “Flows” based upon the 20-bit “Flow Label” value can be done dynamically with minimal effort and configuration of the end-point routers of the flow. The flows can be managed or open, encrypted or in the clear, and will allow for greater scalability, security, and agility in the management and operation of networks. "IPv6 Header Compression via Addressing Mitigation Protocol (IPv6 AMP)", Martin Beckman, 9-Mar-07, This document outlines a methodology for IPv6 Header Compression via mapping the source and destination addresses into a flow label value per address pair sessions with a specific traffic class field value to identify the packet as “address-less” compressed header. The resultant headers, sans addresses shrink from 320 bits to 64 bits. This mapping is locally specific to the router port and the connecting hosts/router ports. Specifically written for use on low bandwidth links (less than T1 or 1.544Mbps), IPv6 AMP’s applicability goes to integration of cellular/WiFi appliances and will be critical for tactical uses for military and first responder applications. "Application of PANA framework to DSL networks", Lionel Morand, Alper Yegin, Yoshihiro Ohba, John Kaippallimalil, 16-May-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. "IMAP4 Multimailbox SEARCH Extension", Barry Leiba, Alexey Melnikov, 22-Apr-08, The IMAP4 specification allows the searching only of the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round-trips and waiting for various searches to complete. This also introduces mailbox field in ESEARCH responses, allowing a client to pipeline the searches if it chooses.Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to ietf-imapext@imc.org. "Congestion Control in the RFC Series", Michael Welzl, Wesley Eddy, 22-Sep-08, This document is an informational snapshot produced by the IRTF's Internet Congestion Control Research Group (ICCRG). It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards. "Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer", Douglas Stebila, 1-Oct-08, This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. "DAI Parameter for the "tel" URI", James Yu, David Hancock, Flemming Andreasen, 12-Jun-08, This document defines a "dai" parameter for the "tel" Uniform Resource Identifier (URI) to support the Dial Around Indicator (DAI). The "dai" parameter is associated with the "cic" parameter, defined in [RFC4694], and indicates how the carrier identified in the "cic" parameter was selected. This document also expands the use of the "cic" parameter to support pre-subscribed and dialed long-distance carrier requirements. "Atom Bidirectional Attribute", James Snell, 11-Apr-08, This document adds a new attribute to the Atom Syndication Format used to indicate the base directionality of directionally-neutral characters. "Requirements for vertical handover of multimedia sessions using SIP", Saverio Niccolini, Stefano Salsano, Haruki Izumikawa, Ross Lillie, Luca Veltri, Yoji Kishi, 8-Jul-08, A vertical handover occurs in heterogeneous networks when a session media is moved among different access network technologies within the same device. This document analyses the issue of handling the vertical handover using the Session Initiation Protocol (SIP) [1]. "GSSAPI authentication for HTTP", Leif Johansson, 13-Jul-08, This document specifies an extention to the HTTP Negotiate authentication mechanism defined in RFC4559 which supports mutual authentication, fast session-based reauth and channel bindings. "Extensible Messaging and Presence Protocol (XMPP): Core", Peter Saint-Andre, 18-Sep-08, This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920. "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", Peter Saint-Andre, 12-Jul-08, This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with RFC 2779. This document obsoletes RFC 3921. "A Uniform Resource Name Namespace For The GSM Association (GSMA) and the International Mobile station Equipment Identity(IMEI)", Andrew Allen, David McDonald, Michael Montemurro, 1-Oct-08, This specification defines a Uniform Resource Name namespace for the GSMA and sub namespaces for the IMEI (International Mobile station Equipment Identity), and for the IMEISV (International Mobile station Equipment Identity and Software Version number). The IMEI is 15 decimal digits long and the IMEISV is 16 decimal digits long and are both encoded using Binary Encoded Decimal (BCD). The IMEI and IMEISV were introduced as part of the specification for Global System for Mobile (GSM) and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, and the Universal Mobile Telecommunications System (UMTS). The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA (GSM Association). "Sharing Transaction Fraud Data", Sharon Boeyen, Michael Grandcolas, Siddharth Bajaj, David M'Raihi, 25-Aug-08, This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format. "Simple SIP Usage Scenario for Applications in the Endpoints", Henry Sinnreich, Alan Johnston, Eunsoo Shim, Kundan Singh, 29-May-08, For Internet-centric usage, the number of SIP related standards for presence, IM and audio/video communications can be reduced by using only the rendezvous and session initiation capabilities of SIP. Such 'simple SIP' implies (1) using SIP without network based features and (2) without emulating the telephone network. Rich applications, including telephony features can however be implemented in the endpoints. This approach for SIP reduces the number of SIP standards to comply with, currently from roughly 100 to about 9. Additional application examples and references for NAT traversal and for security are also provided. "Session Initiation Protocol (SIP) Overload Control", Volker Hilt, Indra Widjaja, Henning Schulzrinne, 13-Jul-08, Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines an overload control mechanism for SIP. "IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications", James Polk, 14-Jul-08, This document creates and IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. "Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, and Other Crimeware", Patrick Cain, David Jevans, 30-Jul-08, This document extends the Incident Object Description Exchange Format (IODEF) to support the reporting of phishing, fraud, other types of electronic crime, and widespread spam incidents. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle. Both simple reporting and complete forensic reports are possible, as is consolidated reporting of multiple phishing incidents. The extensions defined in this document are used to generate two different types of reports: a fraud and phishing report and a wide- spread spam report. Although similar in structure, each report has different required objects and intents.RFC 2129 Keywords "HELD Identity Extensions", James Winterbottom, 14-Jul-08, When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of arriving message as a pointer to the location determination process. This is 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. This extension is used in conjunction with HELD to provide Target identification, and set of criteria of when to use this extensions are provided. Examples and usage in HELD message syntax are also shown. "A Process for Handling Essential Corrections to the Session Initiation Protocol (SIP)", Keith Drage, 2-Jul-08, The Session Initial Protocol (SIP) defined in RFC 3261 and a large number of extensions forms a considerable body of work, which through sheer size has a number of errors that require correction. This document explains the process for managing essential corrections to SIP. "The SIEVE mail filtering language - extension for accessing mailbox metadata", Alexey Melnikov, 21-Jun-08, This memo defines an extension to the SIEVE mail filtering language (RFC 3028) for accessing mailbox and server annotations (variables). "An uniform format for IPv6 extension headers", Suresh Krishnan, James Woodyatt, Erik Kline, James Hoagland, 3-Oct-08, In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document defines a format for defining a new family of IPv6 extension headers. "Experience of implementing NETCONF over SOAP", Iijima Tomoyuki, Yoshifumi Atarashi, Hiroyasu Kimura, Makoto Kitani, Hideki Okita, 18-Aug-08, This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF client and server. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. "The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions", Arnt Gulbrandsen, Intellectual Property, 9-May-08, The SEARCH=INTHREAD extension extends the IMAP SEARCH command to operate on threads as well as individual messages. Other commands which search are implicitly extended. The THREAD=REFS extension provides a threading algorithm using only the References header field for use with the IMAP THREAD command.1. Conventions Used in This Document "Diameter Congestion Signaling", Tolga Asveren, Victor Fajardo, 15-Jul-08, Diameter base protocol defines the network layer functionality to be used by applications. This document adds hop-to-hop congestion notification mechanism to that functionality. "Credential Protection Ciphersuites for Transport Layer Security (TLS)", Ibrahim Hajjeh, 6-Oct-08, This document defines a set of cipher suites to add client credential protection to the Transport Layer Security (TLS) protocol. By negotiating one of those ciphersuites, the TLS clients will be able to determine for themselves when, how, to what extent and for what purpose information about them is communicated to others. The ciphersuites defined in this document can be used only when public key certificates are used in the client authentication process. "IODEF/RID over SOAP", Brian Trammell, Kathleen Moriarty, 25-Feb-08, Documents intended to be shared among multiple constituencies must share a common format and transport mechanism. The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange. This draft outlines the SOAP wrapper for all IODEF documents and extensions to facilitate an interoperable and secure communication of documents. The SOAP wrapper allows for flexibility in the selection of a transport protocol. The transport protocols will be provided through existing standards and SOAP binding, such as SOAP over HTTP/TLS and SOAP over BEEP. "Real-time Inter-network Defense", Kathleen Moriarty, 15-Apr-08, Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms across for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. "Dynamic Host Configuration Protocol Option for Geodetic Location Information", Martin Thomson, James Winterbottom, 3-Jul-08, This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with an indication of uncertainty for each. Separate parameters indicate the reference datum for each of these values. "Suite B Cipher Suites for TLS", Margaret Salter, Eric Rescorla, Russ Housley, 2-Oct-08, The United States Government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document defines a profile of TLS which is conformant with Suite B. "FTP EXTENSION ALLOWING IP FORWARDING (NATs)", Martin Rosenau, 18-Sep-08, The FTP protocol [1] needs two connections. A control and a data connection. Using networks with "port forwarding" (eg. SSH, DSL routers, VPN etc.) there is often only the possibility for the server to listen on only one TCP port. In such networks the traditional FTP protocol cannot be used. This memo describes an extension to the FTP protocol that allows the use of FTP using only one TCP port number for both control connections and passive-mode data connections. The extension can also be used to use the FTP protocol over network protocols that do not have a "port" concept (such as the NetBIOS protocol). "A Conference List Information Event Package for the Session Initiation Protocol (SIP)", Michael Fortinsky, Ilan Ravid, Oded Koren, 3-Jul-08, This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications related to conference lists. A new conference list event package is specified. This event package allows a user to subscribe to a single event (the conference-list) and receive notifications that contain the list of conferences to which the user belongs and the status of each conference. The notifications sent from the conference server can contain either the entire list of the user's conferences or a partial list with the updates since the previous notification. "Bounce Address Tag Validation (BATV)", John Levine, Dave Crocker, Sam Silberman, Tony Finch, 12-May-08, The envelope of Internet mail contains an RFC2821.MailFrom command, which may supply an address to be used as the recipient of transmission and delivery notices about the original message. Existing Internet mail permits unauthorized use of addresses in the MailFrom command, causing notices to be sent to unwitting and unwilling recipients. Bounce Address Tag Validation (BATV) defines an extensible mechanism for validating the MailFrom address. It also defines an initial use of that mechanism which requires no administrative overhead and no global implementation. This document is a revision of draft-levine-mass-batv-02. "IEEE 802.21 Basic Schema", Kenichi Taniuchi, Yoshihiro Ohba, Subir Das, 19-Aug-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, 23-Jun-08, This file is a proposal for P2P based Domain Name query stratagy in IpV6. The DNS servers construct n-tuple overlay virtual hierarchical overlay network. With cached addresses of DNS servers, the overload of traffic in tree structure can be avoided. This strategy may use for Domain Name query and reverse Domain Name query in IpV6 for a large number of domain names. "Locator/ID Separation Protocol (LISP)", Dino Farinacci, Vince Fuller, David Oran, Dave Meyer, Scott Brim, 10-Oct-08, This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS), which took place in October 2006. "Anonymous Layers Identifiers (ALIen): Threat Model for Mobile and Multihomed Nodes", Wassim Haddad, Erik Nordmark, Francis Dupont, Marcelo Bagnulo, Basavaraj Patil, Hannes Tschofenig, 25-Jun-08, This memo describes privacy threats related to the MAC and IP layers identifiers in a mobile and multi-homed environment. "Anonymous Layers Identifiers for Mobile and Multi-homed Nodes: Problem Statement", Wassim Haddad, Erik Nordmark, Francis Dupont, Marcelo Bagnulo, Basavaraj Patil, 25-Jun-08, This memo describes the anonymous layers identifiers in mobility and multi-homing problem statement. "Progress notifications for HTTP", Andrien de Croy, 23-Jul-08, This document specifies an extension to HTTP to allow the sending of progress messages to user-agents during lengthy processing which could otherwise cause users or user-agents to abandon requests. "Requirements for the XCON-DCON Synchronization Protocol", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 20-Jun-08, The Distributed Conferencing (DCON) framework provides the means to distribute Centralized Conference (XCON) information by appropriately orchestrating a number of centralized focus entities (clouds). The mechanism we propose to make each XCON cloud communicate with its related DCON peer is based on the use of some kind of XCON-DCON Synchronization Protocol (XDSP). This document gives the requirements for XDSP. "Requirements for Distributed Conferencing", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 20-Jun-08, This document examines the requirements for Distributed Conferencing (DCON). Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guideline for building interoperable conferencing applications. The current works in SIPPING and XCON working groups marginally address the matter, which is nonetheless considered as out-of-scope. The requirements listed in this document are in part based on thoughts derived from the cited working groups activities. "A Framework for Distributed Conferencing", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 20-Jun-08, This document defines the framework for Distributed Conferencing (DCON). The framework draws inspiration from the work carried out in the XCON working group, which has defined a complete architecture for centralized conferencing. DCON is based on the idea that a distributed conference can be setup by appropriately orchestrating the operation of a number of XCON focus elements, each in charge of managing a certain number of participants. Interaction between each participant and the corresponding conference focus is based on the standard XCON framework, whereas inter-focus interaction is defined in this document. "PSTN scope of PCN Charter", Stuart Goldman, Robert Schafer, Frank Suraci, Bob Schaefer, 5-Jul-08, The IETF PCN Working Group has continued its work investigating pre- congestion and admission control mechanisms. This work has progressed under the current charter, but has not yet considered related legacy PSTN interactions or the need for ubiquitous connectivity between users on dissimilar networks. The PCN charter could be improved by a strong positive statement to the effect committing to future work addressing legacy networks. In that light, please consider the questions below which include differential PCN treatment based on traffic types, security, and PSTN interoperability concerns. It seems helpful to have a touchstone of some concerns relative to the PSTN network and IP network Gateway in order to confirm that they will be addressed in future work. This attempt is motivated by a desire to avoid the accidental omission of a topic that may be hard to "retrofit" in later. "Service Selection for Mobile IPv4", Jouni Korhonen, Ulf Nilsson, 3-Sep-08, In some Mobile IPv4 deployments identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription. This document describes a Service Selection Extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for the mobility service subscription during the registration procedure. "Common Architecture Label IPv6 Security Option (CALIPSO)", Michael StJohns, 25-Aug-08, This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level secure (MLS) networking environments that are both trusted and trustworthy. "DHCP Vendor-specific Message", Bernie Volz, 7-Jul-08, This document requests a vendor-specific DHCPv6 message assignment. This message can be used for vendor specific and experimental purposes. "Public Key Cryptography Based User-to-User Authentication - (PKU2U)", Larry Zhu, Jeffrey Altman, Nicolas Williams, 8-Sep-08, This document defines a Generic Security Services Application Program Interface (GSS-API) mechanism based on Public Key Infrastructure (PKI) - PKU2U. This mechanism is based on Kerberos V messages and the Kerberos V GSS-API mechanism, but without requiring a Kerberos Key Distribution Center (KDC). "The stale-if-error HTTP Cache-Control Extension", Mark Nottingham, 8-May-08, The stale-if-error HTTP Cache-Control extension improves availability of some kinds of cached content by allowing servers and clients to instruct caches to use stale responses when certain error conditions are encountered. "The stale-while-revalidate HTTP Cache-Control Extension", Mark Nottingham, 8-May-08, The stale-while-revalidate HTTP response Cache-Control extension allows servers to instruct caches to serve stale responses while validating them, to avoid latency in some situations. "Supporting Multiple Path Routing in the Session Initiation Protocol (SIP)", Dale Worley, 6-Jul-08, An increasing number of SIP architectures implement multiple path routing (MPR), which is the providing of more than one path for a call to reach a destination user agent (UA). To implement MPR well, the proxy which forks a request onto the redundant paths needs to be able to determine if a fork that failed reached the destination UA and was rejected by the UA (and so an alternate path should not be tried), or if the fork failed before reaching the UA (and so an alternate path should be attempted). This document is to begin a discussion of strategies for making this determination. "A BEEP Binding for the HELD Protocol", Martin Thomson, James Winterbottom, 3-Jul-08, A BEEP binding is described for HELD. This binding is more suitable than the basic HTTP binding in scenarios where multiple messages are sent between the same two parties. "Digital Signature Methods for Location Dependability", Martin Thomson, James Winterbottom, 3-Jul-08, The dependability of location information is closely related to the degree of trust placed in the source of that information. This document describes techniques that can be used to mitigate the impact of falsifying location information. The application of digital signatures is described, relating these methods to the attacks that they address. "Vouch By Reference", Paul Hoffman, John Levine, Arvel Hathcock, 9-Oct-08, This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. "A solution for vertical handover of multimedia sessions using SIP", Stefano Salsano, Saverio Niccolini, Luca Veltri, Andrea Polidoro, 7-May-08, This document proposes a solution for handling vertical handovers among different network technologies using SIP, fulfilling a set of requirements discussed in the document "Requirements for vertical handover of multimedia sessions using SIP" (draft-niccolini-sipping-siphandover-03). The solution requires a new header field (named "Handover") and a new parameter in the Via header field (named "MMID"). "FCAST: Scalable Object Delivery for the ALC and NORM Protocols", Vincent Roca, Brian Adamson, 2-Oct-08, This document introduces the FCAST object (e.g., file) delivery application on top of the ALC and NORM reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service. "Media Gateway Control Protocol Voiceband Data Package and General Purpose Media Descriptor Parameter Package", Sandeep Sharma, Joe Stone, Rajesh Kumar, 3-Jul-08, This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from voiceband data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to the definition of these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy and FEC. "SIP URI Service Discovery using DNS-SD", Jae Woo Lee, Henning Schulzrinne, Wolfgang Kellerer, Zoran Despotovic, 12-Jul-08, This document describes how to use the DNS-based Service Discovery (DNS-SD), better known as Apple Bonjour, for advertising Session Initiation Protocol (SIP) URIs in local area networks. Using this mechanism, a SIP user agent (UA) can communicate with another UA even when no SIP registrar is available, as in a wireless ad-hoc network for example. "IP Tunneling Optimization in a Mobile Environment", Wassim Haddad, Mats Naslund, Pekka Nikander, 13-Jul-08, This memo introduces a simple tunneling optimization mechanism, which removes the need for inserting an additional header in the IP packet. The main goals are to minimize the packet size, provide a simpler protocol design and a better efficiency. "MANET Position and Mobility Signaling: Problem Statement", Jerome Haerri, Christian Bonnet, Fethi Filali, 14-Jul-08, This document states the problem of optimizing the structures created by mobile network or MANET protocols to a mobile network topology. It also justifies the use and the transmission of position information to mitigate this problem. "VPLS Interoperability with Provider Backbone Bridges", Ali Sajassi, 14-Jul-08, The scalability of H-VPLS with Ethernet access network can be improved by incorporating Provider Backbone Bridge (PBB) functionality in VPLS access. PBB is in the process of being standardized as IEEE 802.1ah, which is an amendment to 802.1Q to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This document describes how IEEE 802.1ah functionality can be used in the H-VPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. This document also describes the scenarios and the mechanisms for incorporating PBB functionality within H-VPLS with existing IEEE 802.1ad (aka QinQ) Ethernet access and interoperability among them. "MANET Position and Mobility Signaling Format", Jerome Haerri, Christian Bonnet, Fethi Filali, 14-Jul-08, This document describes an extension to the node metric TLV defined in the MetricTLV document to specify a configurable structure to exchange position and mobility information for MANET protocols. "Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages", Vladislav Marinov, 1-Oct-08, This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG notifications. "Authentication Extensions for the Dynamic Host Configuration Protocol", Richard Pruss, Glen Zorn, Roberta Maglione, Li Yizhou, 18-May-08, 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, 27-Jul-08, This document extends the protocol identifier of SDP so that it could negotiate the use of IKE for media session in SDP offer/answer model. And it also specifies the method to boot up IKE and generate IPsec SA using self-signed certificate under the mechanism of comedia-tls. This document extends RFC 4572. In addition, it defines a new attribute "udp-setup", which is similar to "setup" attribute defined in RFC 4145, to enable endpoints to negotiate their roles in the IKE session. Considering the case that pre-shared keys can be used for authentication in IKE, a new attribute "psk-fingerprint" is also defined. "The Multiple Appearance Feature using the Session Initiation Protocol (SIP)", Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan, Paul Pepper, Anil Kumar, 13-Jul-08, This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as Multiple Appearances (MA) since SIP does not have lines. This feature is commonly offered in the IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This document lists requirements and compares implementation options for this feature. Extensions to the SIP dialog event package are proposed. "Problem Statement and Requirements for 6LoWPAN Mesh Routing", Eunsook Kim, Dominik Kaspar, Carles Gomez, Carsten Bormann, 14-Jul-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. " Security requirements in Peer-to-Peer Session Initiation Protocol (P2PSIP)", Marcin Matuszewski, Haibin Song, XingFeng Jiang, Jan-Erik Ekberg, Pekka Laitinen, 14-Jul-08, This document outlines the security requirements for a Peer-to-Peer Session Initiation Protocol (P2PSIP) overlay network. It compares security difference between client/server (C/S) and P2P implementations of SIP, partitions the P2PSIP architecture into layers and analyzes the security issues in each layer and the security relationship among the layers. This draft also classifies the application scenarios into two main types and then analyzes in detail the security threats with these two types of scenarios. In the end, it summarizes the main security requirements for the P2PSIP architecture and its components. This draft is a merge of features from the P2PSIP security requirements draft and the P2PSIP security analysis and evaluation draft and is still a work in progress. "Network In Node Advertisement", Pascal Thubert, Carlos Bernardos, 12-Sep-08, The Internet is evolving to become a more ubiquitous network, driven by the low prices of wireless routers and access points and by the users' requirements of connectivity anytime and anywhere. For that reason, a cloud of nodes connected by wireless technology is being created at the edge of the Internet. We refer to this cloud as a Fringe Stub (FS). It is expected that networking in the FS will be highly unmanaged and ad-hoc, but at the same time will need to offer excellent service availability. The NEMO Basic Support protocol could be used to provide global reachability for a mobile access network within the FS and the Tree-Discovery mechanism could be used to avoid the formation of loops in this highly unmanaged structure. Since Internet connectivity in mobile scenarios can be costly, limited or unavailable, there is a need to enable local routing between the Mobile Routers within a portion of the FS. This form of local routing is useful for Route Optimization (RO) between Mobile Routers that are communicating directly in a portion of the FS. Network In Node Advertisement (NINA) is the second of a 2-passes routing protocol; a first pass, Tree Discovery, builds a loop-less structure -- a tree --, and the second pass, NINA, exposes the Mobile Network Prefixes (MNPs) up the tree. The protocol operates as a multi-hop extension of Neighbor Discovery (ND), to populate TD-based trees with prefixes, and establish routes towards the MNPs down the tree, from the root-MR towards the MR that owns the prefix, whereas the default route is oriented towards the root-MR. The NINA protocol introduces a new option in the ND Neighbor Advertisement (NA), the Network In Node Option (NINO). An NA with NINO(s) is called a NINA (Network In Node Advertisement). NINA is designed for a hierarchical model, and by using this NA based approach it abstracts the embedded network of a Mobile Router as a host to the upper level of network abstraction. With NINA, a Mobile Router presents its sub-tree to its parent as an embedded network and hides the inner topology and movements. "A Document Format for Expressing Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony", Hannes Tschofenig, Dan Wing, Henning Schulzrinne, Thomas Froment, Geoffrey Dawirs, 12-Jul-08, SPAM, defined as sending unsolicited messages to someone in bulk, might be a problem on SIP open-wide deployed networks. The responsibility for filtering or blocking calls can belong to different elements in the call flow and may depend on various factors. This document defines an authorization based policy language that allows end users to upload anti-SPIT policies to intermediaries, such as SIP proxies. These policies mitigate unwanted SIP communications. It extends the Common Policy authorization framework with additional conditions and actions. The new conditions match a particular Session Initiation Protocol (SIP) communication pattern based on a number of attributes. The range of attributes includes information provided, for example, by SIP itself, by the SIP identity mechanism, by information carried within SAML assertions. "Requirements for Point-to-Multipoint Pseudowire", Frederic JOUNAY, 14-Jul-08, This document presents a set of requirements for providing an unidirectional Point-to-Multipoint PWE3 (Pseudowire Emulation Edge to Edge) emulation. The requirements identified in this document are related to architecture, signaling and maintenance aspects of a Point-to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications Point-to-Multipoint PWs SHOULD be used to optimize the support of multicast services as defined in the Layer 2 Virtual Private Network working group. "Considerations about Multicast for BGP/MPLS VPN Standardization", Thomas Morin, Ben Niven-Jenkins, Yuji Kamite, Raymond Zhang, Nicolai Leymann, Nabil Bitar, 11-Jul-08, The current proposal for multicast in BGP/MPLS includes multiple alternative mechanisms for some of the required building blocks of the solution. The aim of this document is to leverage previously documented requirements to identify the key elements and help move forward solution design, toward the definition of a standard having a well defined set of mandatory procedures. The different proposed alternative mechanisms are examined in the light of requirements identified for multicast in L3VPNs, and suggestions are made about which of these mechanisms standardization should favor. Issues related to existing deployments of early implementations are also addressed. "Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP)", Michael Procter, 17-Aug-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. "Authentication Protocol for Mobile IPv6", Alpesh Patel, Kent Leung, Mohamed Khalil, Haseeb Akhtar, Kuntal Chowdhury, 14-Jul-08, IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6. Mobile IPv6 signalling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing Mobile IPv6 signaling messages between a Mobile Nodes and Home Agents. The alternate method defined here consists of a Mobile IPv6 specific authentication option that can be added to Mobile IPv6 signalling messages. "An Architecture for Human Meetings and Dating websites using other Social Networking Internet resources.", Varun Srivastava, 29-Aug-07, This document describes an architecture for online meetings and dating websites. The proposed architecture can use its own profiles database as well as the other internet based social networking database resources. The document proposes a modular design for online meeting and similar kind of applications on Internet. The architecture proposes an application specific search without breaching privacy of the registered members. It also proposes to utilize member profiles from legacy databases and websites as well as other implementations of this architecture. "The Minger Email Address Verification Protocol", Arvel Hathcock, Jonathan Merkel, 9-Jul-08, This document describes the Minger protocol. Minger is a protocol which allows a mail handling entity to query a remote service and ask the question "do you accept mail for this email address?" It includes security in the form of a hashed shared secret but can also be used anonymously if desired. "The DVB-RCS MIB", Petter Amundsen, Micheline Lambert, Hans-Peter Lexow, Stephane Combes, 4-Sep-08, his document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS). It defines a set of MIB entities to characterize the behavior and performance of network layer entities deploying DVB-RCS. "GRE Key Option for Proxy Mobile IPv6", Ahmad Muhanna, Mohamed Khalil, Sri Gundavelli, Kent Leung, 8-Jul-08, The Proxy Mobile IPv6 base specification and Proxy Mobile IPv6 support for IPv4 allow the mobile node's IPv4 and IPv6 traffic between the local mobility anchor and the mobile access gateway to be tunneled using IPv6 or IPv4 encapsulation headers. These encapsulation modes do not offer the tunnel end-points the required semantics 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 extension defined in this document allow the mobile access gateway and the local mobility anchor to negotiate GRE encapsulation mode and exchange the GRE keys for marking the flows, so that differential processing can be applied by the tunnel peers over those flows. "Extensible Supply-chain Discovery Service Concepts", Michael Young, 29-Aug-08, This document is intended to seed discussion about the Extensible Supply-chain Discovery Service (ESDS), an application layer protocol for the distributed sharing and discovery of notification events between associated partners within a supply chain. Specified initially as a web service interface, the protocol defines event tracking and tracing operations as well as core object management operations. This document obsoletes "Extensible Supply-chain Discovery Service Concepts draft-young-esds-concepts-03". Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). "Extensible Supply-chain Discovery Service Commands", Frank Thompson, 29-Aug-08, The Extensible Supply-chain Discovery Service (ESDS) is an application layer protocol for the distributed sharing and discovery of notification events between associated partners within a supply chain. This document describes the details of the command interface of the ESDS. A full outline of all primary and support commands is included in this document along with examples. Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). "Extensible Supply-chain Discovery Service Schema", Frank Thompson, 29-Aug-08, The Extensible Supply-chain Discovery Service (ESDS) is an application layer protocol for the distributed sharing and discovery of notification events between associated partners within a supply chain. This document outlines the schema of the ESDS application layer protocol. This is the formal syntax of the web service interface specification in Web Service Description Language (WSDL) and XML Schema (XSD). Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). "Adding Acknowledgement Congestion Control to TCP", Sally Floyd, Intellectual Property, 14-Jul-08, This document adds an optional congestion control mechanism for acknowledgement traffic (ACKs) to TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts, the TCP data sender and the TCP data receiver. The TCP data sender detects lost and ECN-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in DCCP's CCID 2. This acknowledgement congestion control mechanism is being proposed as an experimental mechanism for TCP for evaluation by the network community. "The Session Initiation Protocol (SIP) P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem", Hans Erik van Elburg, 7-Sep-08, This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Subsystem Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. "Campus/Building Relative Location for Civic Location Format", Marc Linsner, Allan Thomson, 14-Jul-08, This document defines additional civic address parameters for use in Location Objects [1], [2], and [4]. The format is based on the civic address definition of PIDF-LO. These additional parameters allow expression of a relative location within a building or campus. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Guidelines for Free Standards in the IETF", Simon Josefsson, 23-Apr-08, 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. "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. "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, 5-May-08, This document defines an optional extension block, called a Retransmission Block, that may be used with the Bundle Protocol [2] within the context of a Delay-Tolerant Network architecture [4]. The Retransmission Block (RB) is designed to be inserted by a custodian when re-forwarding a bundle, so as to mark the bundle as a legitimate custody-based retransmission rather than an unauthorized bundle duplicate. By providing a way for nodes that receive the re- forwarded bundle to distinguish it from an unauthorized duplicate, the RB enables those nodes whose local security policies do not permit them to forward unauthorized duplicate bundles to detect and delete unauthorized bundle duplicates but forward legitimate custody- based bundle retransmissions. This document defines the format and processing of this new Retransmission Block. "Application Listener Discovery (ALD) for IPv6", James Woodyatt, 31-Jul-08, This document specifies the protocol used by IPv6 nodes comprising stateful packet filters to discover the transport addresses of listening applications (that is, application endpoints for which incoming traffic may be administratively prohibited). Comments are solicited and should be sent to the author and the V6OPS Residential CPE Design Team mailing list at . "An XCON Client Conference Control Package for the Media Control Channel Framework", Chris Boulton, Mary Barnes, 20-Aug-08, The Centralized Conferencing framework defines a model whereby client initiated interactions are required for creation, deletion, manipulation and querying the state of a of conference. This document defines a Media Control Channel Package for XCON client initiated Conference Control. The Package is based on the Media Control Channel Framework, which is also used for media server control, thus optimizing the implementation for some entities participating in an XCON system. "802.1ah Ethernet Pseudowire", Luca Martini, Ali Sajassi, 25-Jul-08, An Ethernet Pseudowire (PW) is used to carry Ethernet/802.1ah frames over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of 802.1ah Ethernet Frames within a pseudo wire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. "LC-PCN: The Load Control PCN Solution", Lars Westberg, Anurag Bhargava, Attila Bader, Georgios Karagiannis, Hein Mekkes, 14-Jul-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 LC-PCN is kept to a minimum to make implementation simple. LC-PCN can support the ingress-egress-aggregate (i.e., trunk/pipe) bandwdith management model as well as the HOSE bandwidth management model. "Performance Analysis of Inter-Domain Path Computation Methodologies", Sukrit Dasgupta, Jaudelice Oliveira, JP Vasseur, 14-Jul-08, This document presents a performance comparison between the per- domain path computation method and the Path Computation Element (PCE) Architecture based Backward Recursive Path Computation (BRPC) procedure. Metrics to capture the significant performance aspects are identified and detailed simulations are carried out on realistic scenarios. A performance analysis for each of the path computation methods is then undertaken. "Multiple Packetization Times in the Session Description Protocol (SDP): Problem Statement, Requirements & Solution", Marc Willekens, Miguel Garcia, Peili Xu, 13-Jul-08, This document provides a problem statement and requirements with respect to the presence of a single packetization time (ptime/ maxptime) attribute in SDP media descriptions that contain several media formats (audio codecs). Furthermore, a best common practice solution for the use of 'ptime/maxptime' is proposed based on 'static', 'dynamic' and 'indicated' values. Some methods already proposed as ad-hoc solutions and background information is included in an appendix. "Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions", Vince Mammoliti, Carlos Pignataro, Peter Arberg, John Gibbons, Paul Howard, 12-May-08, 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", Gorry Fairhurst, Thomas Schmidt, Matthias Waehlisch, 18-Jul-08, This document discusses current mobility extensions to IP layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and for mobile senders using Any Source Multicast and Source Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual roadmap for initial steps in standardization for use by future mobile multicast protocol designers. "IPv6 Configuration in IKEv2", Pasi Eronen, 4-Jul-08, When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document describes the limitations of current IKEv2 configuration payloads for IPv6, and explores possible solutions that would allow IKEv2 to set up full- featured virtual IPv6 interfaces. "Timezone Information in HTTP", Stefanos Harhalakis, 1-Oct-08, This document defines a HTTP header for clients to provide timezone information to web servers. An ABNF description of the corresponding header is provided. "Handle Resolution Option for ASAP", Thomas Dreibholz, 4-Oct-08, This document describes the Handle Resolution option for the ASAP protocol. "TLS using EAP Authentication", Yoav Nir, Hannes Tschofenig, Peter Gutmann, 8-Jul-08, This document describes an extension to the TLS protocol to allow TLS clients to authenticate with legacy credentials using the Extensible Authentication Protocol (EAP). This work follows the example of IKEv2, where EAP has been added to the IKEv2 protocol to allow clients to use different credentials such as passwords, token cards, and shared secrets. When TLS is used with EAP, additional records are sent after the ChangeCipherSpec protocol message and before the Finished message, effectively creating an extended handshake before the application layer data can be sent. Each EapMsg handshake record contains exactly one EAP message. Using EAP for client authentication allows TLS to be used with various AAA back-end servers such as RADIUS or Diameter. TLS with EAP may be used for securing a data connection such as HTTP or POP3. We believe it has three main benefits: o The ability of EAP to work with backend servers can remove that burden from the application layer. o Moving the user authentication into the TLS handshake protects the presumably less secure application layer from attacks by unauthenticated parties. o Using mutual authentication methods within EAP can help thwart certain classes of phishing attacks. "Design and Application Spaces for 6LoWPANs", Eunsook Kim, Nicolas Chevrollier, Dominik Kaspar, JP Vasseur, 14-Jul-08, This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). "Use of the Identity-Based Cryptographic Algorithms in CMS", Zhaohui Cheng, Bo Dan, 13-Apr-08, This document describes the conventions for using identity-based cryptography algorithms in the Cryptographic Message Syntax (CMS). "EAP-Based Keying for IP Mobility Protocols", Vidya Narayanan, Gerardo Giaretta, 16-Nov-07, EAP [1] is increasingly used for network access authentication in various networks. Also, key generating EAP methods are being adopted in various systems for the purposes of cryptographic protection between an EAP peer and an enforcement point in the network. Key generating EAP methods produce an MSK and an EMSK in accordance with [1]. The MSK is meant for use by the EAP lower layer at the peer and the authenticator and is used differently by various lower layers. The EMSK hierarchy is defined in [2]. The EMSK hierarchy is meant to be extensible to derive keys for various usages. This document defines the key hierarchy and key derivations for using the EMSK hierarchy for keying in IP mobility protocols. "Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing Zhou, 11-Jul-08, This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. "A Framework to tackle Spam and Unwanted Communication for Internet Telephony", Hannes Tschofenig, Henning Schulzrinne, Dan Wing, Jonathan Rosenberg, David Schwartz, 14-Jul-08, Spam, defined as sending unsolicited messages to someone in bulk, is likely to become a problem on SIP open-wide deployed networks. A number of solutions have been proposed for dealing with Spam for Internet Telephony (SPIT) and unwanted communication, such as content filtering, black lists, white lists, consent-based communication, reputation systems, address obfuscation, limited use addresses, turing tests, computational puzzles, payments at risk, circles of trust, and many others. This document describes the big picture that illustrates how the different building blocks fit together and can be deployed incrementally. "Requirements for Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony", Hannes Tschofenig, Geoffrey Dawirs, Thomas Froment, Dan Wing, Henning Schulzrinne, 11-Jul-08, Spam over Internet Telephony (SPIT) is one of the foreseen future forms of spamming that SIP open-wide networks may have to handle. SPIT also has more impact on users than email spam since it is more intrusive. Email as a store-and-forward communication mechanism allows for several filtering mechanisms to be applied to the full content before being presented to the user. Session Initiation Protocol (SIP) interaction is, in contrast, real-time communication and therefore does not provide much information prior to the transmission of the content, making it both harder to filter and more annoying to users. The responsibility for filtering, blocking calls, or taking any other preventive action can belong to different elements in the call flow and may depend on various factors. This document discusses the requirements to define authorization policies that should allow end users or other parties to setup anti-SPIT policies for triggering these actions. These policies typically match a particular SIP communication pattern based on a number of attributes. The range of attributes includes information provided, for example, by the SIP protocol itself, by the SIP identity mechanism, by information carried within SAML assertions or by reputation systems of social networks. "MIKEY DHHMAC-SAS: The New MIKEY Transportation Mode", Alexandre Barreto, Antonio Faleiros, 18-Jun-07, This document presents a new transport mode to the Multimedia Internet KEYing (MIKE) protocol, the MIKEY-DHHMAC-SAS. The MIKEY has as its objective the negotiation of cryptography parameters necessaries to the establishment of a secure (SRTP/SRTCP) end-to-end multimedia channel, but all its operation modes have some kind of limitation that prevents it of being used to this purpose. The MIKEY-DHHMAC-SAS solves theses existing limitations in MIKEY-DH and MIKEY-DHHMAC modes by adding the features of key continuity and Short Authentication String (SAS), making possible its use in any end-to- end multimedia scenario. "Commissioning in 6LoWPAN", Ki-Hyung Kim, Chae-Seong Lim, Seung Yoo, Soohong Daniel Park, Geoffrey Mulligan, 17-Jul-08, The commisioning process defines the startup procedure executed by any 6LoWPAN device. This document defines the startup procedure that should be followed by a 6LoWPAN device in any open or secured network. "Guidelines for Using the Privacy Mechanism for SIP", Mayumi Munakata, Shida Schubert, Takumi Ohba, 25-Sep-08, This is an informational document that provides guidelines for using the privacy mechanism for Session Initiation Protocol (SIP), that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and SDP parameters for each of the privacy header values (priv-values). "ECC Brainpool Standard Curves and Curve Generation", Manfred Lochter, Johannes Merkle, 4-Aug-08, This Memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). "REsource LOcation And Discovery (RELOAD)", Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, 10-Jun-08, This document defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes which do not need to route traffic or store data for others. "Header Protection for S/MIME", Lijun Liao, Joerg Schwenk, 6-Oct-08, In the current S/MIME Version 3.1 specification, the header protection is achieved by encoding the whole message as a message/rfc822 MIME object. Since this approach poses some practical problems, we propose to use signed attributes to implement a fully backward compatible S/MIME header protection scheme. "Applicability Statement for SecureMail: A framework for increasing email security", Michael Pearson, Ferry Hendrikx, Matthew Hunt, 29-Apr-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. Comments are solicited and should be addressed to the mailing list at securemail-discuss@googlegroups.com and/or the authors. "HELD Protocol Context Management Extensions", James Winterbottom, Hannes Tschofenig, Martin Thomson, 29-Sep-08, This document describes a protocol extension for the HTTP Enabled Location Delivery (HELD) protocol. It allows a Target to manage their location information on a Location Information Server (LIS) through the application of constraints invoked by accessing a location URI. Constraints described in this memo restrict how often location can be accessed through a location URI, how long the URI is valid for, and the type of location information returned when a location URI is accessed. Extension points are also provided. "secure anycast tunneling protocol (SATP)", Othmar Gsenger, 6-May-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 methods used by the Secure Real-time Transport Protocol(SRTP) [1]. It can be used as an encrypted alternative to IP Encapsulation within IP [3] and Generic Routing Encapsulation (GRE) [4]. Both anycast receivers and senders are supported. "Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests", Robert Sparks, 3-Jul-08, This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (200 class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. "Diameter Proxy Mobile IPv6: Support For Mobile Access Gateway and Local Mobility Anchor to Diameter Server Interaction", Jouni Korhonen, Julien Bournelle, Ahmad Muhanna, Kuntal Chowdhury, Ulrike Meyer, 15-Sep-08, This specification defines the Diameter support for the Proxy Mobile IPv6 and the corresponding mobility service session setup. The policy information needed by the Proxy Mobile IPv6 is defined in mobile node's policy profile, which could be downloaded from the Diameter server to the Mobile Access Gateway once the mobile node roams into a Proxy Mobile IPv6 Domain and performs access authentication. "Internationalized Resource Identifiers (IRIs)", Martin Duerst, Michel Suignard, 3-Aug-08, This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement to the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs. [RFC Editor: Please remove this paragraph before publication.] This is a draft to update RFC 3987 and move towards IETF Draft Standard. For an issues list/change log and additional information (including mailing list information), please see http://www.w3.org/International/iri-edit. For discussion and comments on this draft, please use the public-iri@w3.org mailing list. "The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations", Itaru Nishioka, Daniel King, 4-Jul-08, A Path Computation Element (PCE) performing dependent path computations, for instance calculating a diverse working and protected path do not share common network points, would need to synchronize the computations in order to increase the probability of meeting the working and protected path disjoint objective and network resource optimization objective. When a PCE computes multiple sets of dependent path computation requests concurrently, it is required to use Synchronization VECtor (SVEC) list for association among the sets of dependent path computation requests. This document describes the usage of multiple SVECs in the SVEC list and its processing guideline, for the synchronized computation of dependent paths. "MIPv4 Authentication Using a New Diameter MIPv4 Application", Ahmad Muhanna, Mohamed Khalil, Avi Lior, 14-Jul-08, Current Mobile IPv4 deployments use RADIUS based MIPv4 user authentication and authorization. Diameter Mobile IPv4 Application [RFC4004] offers another method for MIPv4 authentication, authorization, and dynamic mobility security association allocation, e.g. MN-HA SA allocation. Some SDOs are considering the use of Diameter Mobile IPv4 Application to replace RADIUS based mechanism. However, these SDos use a link layer access authentication mechanism, e.g., using an EAP application, to derive the related MIP4 shared keys and security association. This document an overview of these respected architectures and their handling to MIP4 security association and keys derivation and distribution. It presents an analysis of the performance and impact of Diameter MIPv4 Application and RADIUS based solutions on the time the mobile node uses during the initial session setup. Some common MIPv4 scenarios which require the mobile node to retransmit its initial RRQ message have been identified and used. The set of assumptions and requirements used for this study has been clearly documented under section 5. "ANCP Multicast Handling Sessions", Roberta Maglione, Angelo Garofalo, Francois Le Faucheur, Toerless Eckert, Tom Taylor, 11-Jul-08, This memorandum aims at presenting ANCP Multicast handling. It proposes updated description of the Multicast Use cases and corresponding updated ANCP requirements. It also presents the corresponding Message Flows. "SIV Authenticated Encryption using AES", Dan Harkins, 26-Jun-08, This memo describes SIV (Synthetic Initialization Vector), 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. "Layered Encapsulation of Congestion Notification", Bob Briscoe, 14-Jul-08, This document redefines how the explicit congestion notification (ECN) field of the outer IP header of a tunnel should be constructed. It brings all IP in IP tunnels (v4 or v6) into line with the way IPsec tunnels now construct the ECN field. It includes a thorough analysis of the reasoning for this change and the implications. It also gives guidelines on the encapsulation of IP congestion notification by any outer header, whether encapsulated in an IP tunnel or in a lower layer header. Following these guidelines should help interworking, if the IETF or other standards bodies specify any new encapsulation of congestion notification. "Emulating Border Flow Policing using Re-PCN on Bulk Data", Bob Briscoe, 13-Sep-08, Scaling per flow admission control to the Internet is a hard problem. The approach of combining Diffserv and pre-congestion notification (PCN) provides a service slightly better than Intserv controlled load that scales to networks of any size without needing Diffserv's usual overprovisioning, but only if domains trust each other to comply with admission control and rate policing. This memo claims to solve this trust problem without losing scalability. It provides a sufficient emulation of per-flow policing at borders but with only passive bulk metering rather than per-flow processing. Measurements are sufficient to apply penalties against cheating neighbour networks. "OpenToken", Dave Smith, Peter Motykowski, Yasir Faruqi, Peter Saint-Andre, 11-Aug-08, This document describes OpenToken (OTK), a format for the lightweight, secure, cross-application exchange of key-value pairs. The format is designed primarily for use as an HTTP cookie or query parameter, but can also be used in other scenarios that require a compact, application-neutral token. "Applicability Issues for Supporting IPsec NAT-Traversal Mechanism in NAT-PT", Sangjin Jeong, Myung-Ki Shin, Sangdo Lee, 14-Jul-08, This document describes applicability issues for supporting IPsec protocol at NAT-PT, which is based on the NAT-Traversal mechanism. "VPLS Extensions for Provider Backbone Bridging", Matthew Bocci, John Hoffmans, Geraldine Calvignac, Raymond Zhang, Florin Balus, 15-Jul-08, IEEE 802.1ah draft standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running (M)STP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. "Fast Handovers for PMIPv6", Hidetoshi Yokota, Kuntal Chowdhury, Rajeev Koodli, Basavaraj Patil, Frank Xia, 13-Jul-08, This document specifies the usage of FMIPv6 when Proxy Mobile IPv6 is applied for the mobility management protocol. Necessary amendments are shown for FMIPv6 to work under the condition that the mobile node does not have IP mobility functionality and it is not involved with either MIPv6 or FMIPv6 operations. "Additional Location Privacy Considerations", Richard Barnes, Matt Lepinski, Hannes Tschofenig, Henning Schulzrinne, 14-Jul-08, This document discusses security and privacy concerns related to the distribution of location information over the Internet. We clarify how privacy rules can be enforced by a location server, and how privacy rules should be interpreted in store and forward networks. We also describe general mechanisms for providing end-to-end assurances about a location object. "Requirements for Authority-to-Individuals Communication for Emergency Situations", Steve Norreys, 14-Jul-08, Public safety agencies need to provide information to the general public before and during large-scale emergencies. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions. This document summarizes requirements for protocols to alert individuals within a defined geographic area. "Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, 12-Jul-08, The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. This document allows CAP documents to be distributed via the event notification mechanism available with the Session Initiation Protocol (SIP). "One-way Passive Measurement of End-to-End Quality", Yutaka Kikuchi, Satoru Matsushima, Kenichi Nagami, Satoshi Uda, Nobuo Ogashiwa, 21-May-08, This draft describes a passive measurement method for one-way end-to- end quality. This method reports both whether a flow of packets is in-sequence or not and error types on detecting out-of-sequence. The method consumes small resource therefore it can be adapted to many protocols that have sequence number field. "Membership Event Package", Vishal Singh, Henning Schulzrinne, Piotr Boni, 14-Jul-08, This document defines a new event membership package that allows to track changes in membership in groups. Groups can represent entities contained within a physical space, such as a room or vehicle, or a logical group of entities, such as a call center team. Each member of a group can support a different set of event packages. "Requirements for configuring Cryptographically Generated Addresses (CGA) and overview on RA and DHCPv6-based approaches", Sheng Jiang, 11-Jul-08, This document analyzes the requirements for the configuration Cryptographically Generated Addresses and Multi-key CGAs. The applicability of Router Advertisement and DHCPv6 for this configuration is also discussed. "An Evaluation Framework for Data Modeling Languages in Network Management Domain", Hui Xu, Debao Xiao, 17-Jun-08, With rapid development of next generation networks, it is expected that a separate effort to study data modeling languages in the interest of network management should be undertaken. Based on a good understanding of the requirements of data modeling in next generation network management domain, evaluation on management data modeling languages becomes an essential way for the purpose of standardization to replace proprietary data models in the near future. Our project aims to establish a framework for evaluation to measure the capabilities of management data modeling languages in meeting those requirements by a set of criteria, which are modeling approaches, interoperability, readability, conformance, data representation, extensibility and security considerations. "File Transfer Protocol HOST Command", Paul Hethmon, Robert McMurray, 14-Jul-08, The File Transfer Protocol, as defined in RFC 959 [1] and RFC 1123 Section 4 [6], is one of the oldest and widely used protocols on the Internet. This document addresses the subject of creating multi-homed FTP hosts servers on a single IP address. This is achieved by extending the FTP specification to add a HOST command that is used to specify individual FTP hosts. "Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions", Minpeng Qi, Haitao Li, Peng Yang, Hui Deng, Yuanchen Ma, 14-Jul-08, This draft discusses the issues associated with interfacing between IKEv2/IPsec and MIPv6. When mobile nodes bootstrap in foreign network or handover to a new network, IKEv2/IPsec can not probe the changing of care-of-address, which is related security associations. One simple extension to the SADB_ACQUIRE in PF_KEY framework is proposed to support this interfacing. And the operation modification of IKEv2 and MIPv6 are described in this proposal based on the SADB_ACQUIRE extension. A new mobility security reference database is created to store the temporary mobility parameters. "Open Research Issues in Internet Congestion Control", Dimitri Papadimitriou, 8-Aug-08, This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet- scale solutions can be confidently engineered and deployed. "PKI Resource Query Protocol (PRQP)", Massimiliano Pala, 30-Jun-08, One of the most strategic problems still open in PKIX is locating public data and services associated with a Certification Authority (CA). This issue impacts interoperability and usability in PKIX. This draft describes the PKI Resource Query Protocol (PRQP), its design, definition, and its impact in already deployed PKIX protocols. "A Solution For Source Address Validation in Local Subnet Environment", Jianping Wu, Gang Ren, Jun Bi, Xing Li, Mark Williams, 14-Jul-08, This document describes a solution for preventing source address spoofing in the local subnet of the Internet. The main idea of the solution is to get a dynamic binding between IP address and access switch port. "Administrative Specific Elements for Civic Location Format", Marc Linsner, Subha Dhesikan, Hannes Tschofenig, 14-Jul-08, This document defines additional civic address parameters for use in Location Objects [1], [2], and [4]. The format is based on the civic address definition of PIDF-LO. These addition parameters allow expression of administrative specific location data elements. "Ivip (Internet Vastly Improved Plumbing) Architecture", Robin Whittle, 19-Aug-08, Ivip (Internet Vastly Improved Plumbing) is a proposed global system of routers and either collection of databases which control the tunneling of some of these routers. Database changes affect all Ingress Tunnel Routers (ITRs) within a few seconds, controlling which Egress Tunnel Router (ETR) they tunnel each packet to, depending on the packet's destination address. The ETR used by a host with an Ivip-mapped address is typically located in the same network as this destination host. The ETR decapsulates packets and forwards them to the destination host. A second type of ETR known as a Translating Tunnel Router (TTR) is used for mobile-IP, with the mobile node creating two-way tunnels to one or more nearby TTRs. Ivip enables a subset of IPv4 and IPv6 address space to be portable (used via any ISP which has an ETR) and to be suitable for multihoming (connection to the Net via two or more ISPs) - without involving BGP and without requiring any changes to host operating systems or applications. This is a form of "locator-ID separation" and is based on some principles derived from LISP (Locator/ID Separation Protocol). IP addresses in the subset of address space which is subject to being tunneled by ITRs are known as Destination Identifiers (DIDs). ITRs and ETRs are located on ordinary BGP Reachable IP (BRIP) addresses. The databases and ITRs map DID addresses to an ETR's BRIP address with a granularity of a single IPv4 address or a /64 prefix for IPv6. These two granularities are 256 and 64k times finer than is typically possible with BGP. This proposal is intended to resolve many of the problems discussed in the October 2006 Amsterdam IAB Routing and Addressing Workshop (RAWS). Ivip's primary goals include the more efficient utilisation of IPv4 space and enabling millions of end- users to achieve portability and multihoming without involving BGP, without fuelling the growth of the global BGP routing table, and without requiring these end users to have ASNs or to acquire conventional prefixes of PI (Provider Independent) BGP reachable address space. "Link Metrics for OLSRv2", Christopher Dearlove, Thomas Clausen, Philippe Jacquet, 16-Sep-08, This document describes how link metrics may be added, in a relatively straightforward manner, to the specification of OLSRv2, in order to allow routing by other than minimum hop count routes. In addition to metric signaling and use, the most significant change is a separation of the routing and flooding functions of MPRs. "EAP Fast Re-Authentication Protocol (EAP-FRAP)", Saber Zrelli, Yoichi Shinoda, 3-Jun-08, This document specifies an extension to the AAA/EAP authentication and key management framework that allows an EAP peer to perform fast re-authentications with the local EAP server after an initial full EAP authentication using a legacy EAP method with the same or another EAP server. EAP-FRAP eliminates the need for exchanges between the local EAP server and the home EAP server each time the EAP peers is authenticated. In wireless networks, this allows the mobile device to reduce hand-off delays. The EAP-FRAP extension does not require changes in underlying layer protocols. Which makes is back-ward compatible with existing infrastructures and easily deployable with minimal costs. "The Lightweight Global Navigation Satellite System (GNSS) Support Protocol (LGSP)", Mike Tyson, Carlo Kopp, 21-Dec-07, This document presents the Lightweight GNSS (Global Navigation Satellite System) Support Protocol (LGSP). The Lightweight GNSS Support Protocol (LGSP) is being developed in order to provide a comprehensive solution which solves the problems inherent in traditional radio-based Differential GPS (DGPS) protocols. LGSP will also provide additional support for GNSS user equipment, such as a GPS almanac retrieval method, allowing compatible units to perform faster almanac acquisition, thus resulting in less time until an initial position measurement can be established. Other supporting features include alternative distribution of GPS navigation messages and differential correction messages, a hierarchical mirroring architecture, redundant backup operation and load balancing functions. "Routing and Addressing Problem Statement", Thomas Narten, 15-Apr-08, Note this document is unchanged relative to -01, which recently expired. 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. "Redesignation of 240/4 from "Future Use" to "Private Use"", Paul Wilson, George Michaelson, Geoff Huston, 29-Sep-08, This document directs the IANA to designate the block of IPv4 addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast address space for Private Use. "RAN Synchronization Requirements", LinLang Zhou, 7-Jul-08, This Internet draft describes RAN synchronization requirements, mainly about synchronization description and requirements, also includes some applications and problem description. "Heartbeat Mechanism for Proxy Mobile IPv6", Vijay Devarapalli, Rajeev Koodli, Heeseon Lim, Nishi Kant, Suresh Krishnan, Julien Laganier, 8-Sep-08, Proxy Mobile IPv6 is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA), setup tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures quickly and take appropriate action. "Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices", Henning Schulzrinne, Stephen McCann, Gabor Bajko, Hannes Tschofenig, 12-Jul-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. ""RTP Payload Format for apt-X"", Gregory Massey, 24-Jun-08, This document describes an RTP payload format for transporting apt-X encoded audio. It details the RTP encapsulation mechanism for standard, enhanced apt-X and apt-X Live data. Also included within this memo are media type registrations, and the details necessary for the use of apt-X, enhanced apt-X and apt-X Live with the Session Description Protocol. "A Framework of Media-Independent Pre-Authentication (MPA) for Inter- domain Handover Optimization", Ashutosh Dutta, Victor Fajardo, Yoshihiro Ohba, Kenichi Taniuchi, Henning Schulzrinne, 14-Jul-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. "RFC Editor Proposal for Handling RFC Errata", Sandy Ginoza, Alice Hagens, Robert Braden, 21-May-08, This document describes a web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the book-keeping for handling errata. "Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", Nancy Cam-Winget, Hao Zhou, 30-Jul-08, The flexible authentication via secure tunneling EAP method (EAP- FAST) enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within this tunnel a basic password exchange, based on the generic token card method (EAP-GTC), may be executed to authenticate the peer. "CUBIC for Fast Long-Distance Networks", Injong Rhee, Lisong Xu, Sangtae Ha, 26-Aug-08, CUBIC is an extension to the current TCP standards. The protocol differs from the current TCP standards only in the congestion window adjustment function in the sender side. In particular, it uses a cubic function instead of a linear window increase of the current TCP standards to improve scalability and stability under fast and long distance networks. BIC-TCP, a predecessor of CUBIC, has been a default TCP adopted by Linux since year 2005 and has already been deployed globally and in use for several years by the Internet community at large. CUBIC is using a similar window growth function as BIC-TCP and is designed to be less aggressive and fairer to TCP in bandwidth usage than BIC-TCP while maintaining the strengths of BIC- TCP such as stability, window scalability and RTT fairness. Through extensive testing in various Internet scenarios, we believe that CUBIC is safe for deployment and testing in the global Internet. The intent of this document is to provide the protocol specification of CUBIC for a third party implementation and solicit the community feedback through experimentation on the performance of CUBIC. We expect this document to be eventually published as an experimental RFC. "OSPF Multi-Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 21-Sep-08, OSPFv3 includes a mechanism for supporting multiple instances on the same link. OSPFv2 could benefit from such a mechanism in order to support multiple routing domains on the same subnet. The OSPFv2 instance ID is reserved for support of separate OSPFv2 protocol instances. This is different from OSPFv3 where it could be used for other purposes such as putting the same link in multiple areas. OSPFv2 supports this capability using a separate subnet or the OSPF multi-area adjacency capability. "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, 20-Aug-08, This document describes a Home Agent assisted route optimization extension to IPv4 Network Mobility Protocol. "Diameter Support for EAP Re-authentication Protocol", Lakshminath Dondeti, 14-Jul-08, An EAP extension, called "EAP Re-authentication Protocol (ERP)", has been specified that supports an EAP method-independent protocol for efficient re-authentication between the peer and the server through an authenticator. This document specifies Diameter support for ERP. The Diameter EAP application is re-used for encapsulating the newly defined EAP Initiate and EAP Finish messages specified in the ERP specification. AVPs for request and delivery of Domain Specific Root Keys from the AAA/EAP server to the ER server are also specified. Additionally, this document also specifies Diameter processing rules relevant to ERP. "Connection setup negociation for the Message Session Relay Protocol", Remi Denis-Courmont, 27-Jul-08, This document extends the MSRP connection model to negotiate the direction of the TCP connection setup. This provides a partial yet simple solution for scenarios whereby either, but not both, party to an MSRP session is located behind a NAT or firewall, and cannot serve as the passive endpoint for TCP connection setup. "H.248/MEGACO Package Registration Procedures", Christian Groves, Yangbo Lin, 31-Jul-08, This document updates the H.248/MEGACO IANA Package Registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process. "Agent-based multicast support for moving networks (NEMO)", Dirk von Hugo, 25-Apr-08, 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, 4-Oct-08, This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet layer parameters, as well as parameters affecting higher layer protocols. "IPsec Gateway Failover Protocol", Yaron Sheffer, Hannes Tschofenig, Lakshminath Dondeti, Vidya Narayanan, 12-Jul-08, The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol is used for authentication, which adds several more round trips and therefore latency. To re-establish security associations (SA) upon a failure recovery condition is time consuming, especially when an IPsec peer, such as a VPN gateway, needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In many failure cases it would be useful to provide an efficient way to resume an interrupted IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected, or alternatively migrate to another gateway that is associated with the previous one. The proposed approach conveys IKEv2 state information, in the form of an encrypted ticket, to a VPN client that is later presented to the VPN gateway for re-authentication. The encrypted ticket can only be decrypted by the VPN gateway in order to restore state for faster session setup. "Using Device-provided Location-Related Measurements in HELD", Martin Thomson, James Winterbottom, 8-May-08, A method is described by which a Device is able to provide location- related measurement data to a LIS within a HELD request. Location- related measurement information are observations concerning properties related to the position of a Device, which could be data about network attachment or about the physical environment 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 location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters. "URI Scheme for Java(tm) Message Service 1.0", Dongbo Xiao, Roland Merrick, Peter Easton, Derek Rokicki, Eric Johnson, 22-Apr-08, This document defines the format of Uniform Resource Identifiers (URI) as defined in [RFC3986], for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS) [REF-JMS]. It was originally designed for particular uses, but should have general applicability wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS destination. The syntax of this 'jms' URI is not compatible with any known current vendor implementation, but the expressivity of the format should permit all vendors to use it. "Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP", Preethi Natarajan, Paul Amer, Ertugrul Yilmaz, Randall Stewart, Janardhan Iyengar, 27-Aug-08, Stream Control Transmission Protocol (SCTP) [RFC4960] specifies Selective Acknowledgements (SACKs) to allow a transport layer data receiver to acknowledge DATA chunks which arrive out-of-order. In SCTP, SACK information is advisory because the data receiver is permitted to renege; that is, later discard a DATA chunk which previously has been SACKed. Since delivery of a SACKed out-of-order DATA chunk is not guaranteed, a copy of this DATA chunk MUST be kept in the data sender's retransmission queue until this DATA chunk is cumulatively acked. This document specifies Non-Renegable Selective Acknowledgements (NR- SACKs), an extension to SCTP's acknowledgment mechanism. NR-SACKs enable a data receiver to explicitly acknowledge out-of-order DATA chunks that have been delivered to the receiving application. (Recall that, in SCTP, out-of-order data sometimes can be delivered.) NR-SACKs also enable a data receiver to indicate any out-of-order DATA chunks on which the receiver guarantees never to renege. As opposed to SACKed DATA chunks, a sender can consider NR-SACKed DATA chunks as never requiring retransmission, thus freeing space in the data sender's retransmission queue sooner. "Signaling Extensions for Wavelength Switched Optical Networks", Greg Bernstein, 7-Jul-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, 28-Apr-08, This document describes a new approach to handling user mobility at the network layer in the context of Multi-Protocol Label Switched Networks (MPLS). This approach does not rely on the existing IP mobility management protocols such as Mobile IP, and is instead based on the combination of Multi-Protocol BGP (MP-BGP) and MPLS. This document proposes to introduce new protocol elements to MP-BGP to achieve Mobility Label distribution at the network control plane and the optimal packet delivery to the mobile node by the network forwarding plane using MPLS. "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", Young Lee, Dan Li, Wataru Imajuku, Greg Bernstein, 7-Jul-08, This document provides an information model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of information described in this model is to facilitate constrained lightpath computation in WSONs. In particular in cases where there are no or a limited number of wavelength converters available in the WSON. This model currently does not include optical impairments. "Distributed Universal Resource Name Resolution based on Distributed DNS", Lican Huang, 4-Aug-08, This file is a proposal for Universal Resource Name resolution based on P2P DNS. "Evaluation of Possible Interior Gateway Protocol Extensions for Wavelength Switching Optical Networks", Dan Li, Jianhua Gao, Young Lee, Jianrui Han, Baoquan Rao, Xinghua Shi, 12-Jul-08, Wavelength Division Multiplexing (WDM) is a technology for optical communications, in which the user traffic is carried by data channels of different optical wavelengths. In traditional WDM Networks, each wavelength path is statically configured. With the deployment of the Reconfigurable Optical Add-Drop Multiplexer (ROADM) and the Wavelength Selective Switch (WSS), WDM networks have become more dynamic, and operators can flexibly set up wavelength paths to carry user traffic. This document discusses the set of Interior Gateway Protocol (IGP) requirements that would enable distributed light path computation in Wavelength Switched Optical Networks (WSON). An IGP impact analysis is also provided. According to the analysis, there is no significant impact on the IGP performance. "OCSP Algorithm Agility", Phillip Hallam-Baker, 2-Jul-08, The behavior of an OCSP server is specified for cases in which the OCSP server is capable of supporting more than one signature algorithm. "PCEP Requirements and Extensions for WSON Routing and Wavelength Assignment", Young Lee, Greg Bernstein, 30-Jun-08, This memo provides application-specific requirements and protocol enhancements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Different computational architectures for the RWA process are given and the PCEP extensions needed to support these architectures are defined. "A lightweight security extension for the Unidirectional Lightweight Encapsulation (ULE) protocol", Michael Noisternig, Bernhard Collini-Nocker, 14-Jul-08, The Unidirectional Lightweight Encapsulation (ULE) protocol is an efficient and extensible transport mechanism for IP over MPEG-2 networks. Such networks are often operated on broadcast wireless channels, and are thus specifically vulnerable to attacks. Passive attacks, such as eaves-dropping, are simple to perform and emphasize the importance of security support within ULE. This document defines a mandatory security extension for the ULE protocol that is designed with the aim of being conservative in bandwidth consumption and lightweight in the sense that it allows for implementation in low-cost, resource-scarce (mobile) receiver devices. The extension may be easily adapted to the Generic Stream Encapsulation (GSE) protocol, which uses the same extension header mechanism. The document describes the format of the security extension header, specifies default security algorithms to be used with this extension, and gives detailed processing descriptions for devices implementing the security extension. Conventions used in this document The following DVB specific terms are taken from [RFC4326] and recapitulated here for easy lookup: DVB: Digital Video Broadcast. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data using the ISO MPEG-2 standard [MPEG2]. MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG) and standardized by the International Standards Organization (ISO/IEC 13818-1) [MPEG2] and ITU-T [H222]. NPA: Network Point of Attachment. In this document, refers to a 48- bit destination address (resembling an IEEE MAC address) within the MPEG-2 transmission network that is used to identify individual receivers or groups of receivers. PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. PID: Packet Identifier [MPEG2]. A 13-bit field carried in the header of TS cells. This is used to identify the TS Logical Channel to which a TS cell belongs [MPEG2]. SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 payload unit. TS: Transport Stream [MPEG2]. A method of transmission at the MPEG-2 level using TS cells; it represents layer 2 of the ISO/OSI reference model. TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [MPEG2]. All packets sent over a TS Logical Channel carry the same PID value. ULE: Unidirectional Lightweight Encapsulation [RFC4326]. A protocol that encapsulates PDUs into SNDUs that are sent in a series of TS cells using a single TS Logical Channel. Terms and abbreviations from cryptography are explained when they first appear within this document. All numbers encoded in protocols are to be interpreted in network byte order. "Call on hold for telephony applications of SIP protocol", Daniele Giordano, 20-Aug-08, Many RFCs and Internet Drafts describe call on hold methods adopted in SIP signaling protocol. The actual implementation may not always be ideal for telephony applications (reasons are explained below). This draft proposes a revision of call on hold method for SIP protocol. Giordano [page 1] Internet-Draft Call on hold for telephony applications of SIP protocol "Certificate Profile for SEND", Suresh Krishnan, Ana Kukec, Khaja Ahmed, 14-Jul-08, Secure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND including extended key usage values, revocation details and supported extensions. "Secure Proxy ND Support for SEND", Suresh Krishnan, Julien Laganier, Marco Bonola, 6-Jun-08, Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As specified today, SEND assumes that the node advertising an address is the owner of the address and is in possession of the private key used to generate the digital signature on the message. This means that the Proxy ND signaling initiated by nodes that do not possess knowledge of the address owner's private key cannot be secured using SEND. This document extends the current SEND specification with support for Proxy ND, the Secure Proxy ND Support for SEND. "GMPLS RSVP-TE Extensions to Control Ethernet OAM", Attila Takacs, Balazs Gero, Dinesh Mohan, 11-Jul-08, The GMPLS controlled Ethernet Label Switching (GELS) work is extending GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This memo specifies extensions of GMPLS RSVP-TE to support the setup of the associated Ethernet OAM (CFM and Y.1731) entities for point-to-point Ethernet LSPs.Changes from previous version Two alternative ways to extend RSVP-TE with OAM configuration are summarised in a new appendix ("Discussion on alternatives"). The description of RSVP-TE extensions is restructured; a new section is added ("Technology Independent Extensions") to identify common technology independent extensions. Note, this part may be moved to a separate framework document leaving only the Ethernet specific extensions in this document. Some nits and typos cleared. "Multiple Interfaced Mobile Nodes in NetLMM", Mohana Jeyatharan, 26-Jun-08, The specific mechanism described in the current PMIPv6 draft to support multihoming is such that a unique prefix is given to each interface of a Mobile Node (multiple unique prefixes per MN) that is attached to the PMIPv6 domain. However, multihoming can also be provided using same unique prefix for all interfaces of MN (single unique prefix per MN). This memo explores and highlights some issues associated with multihoming support in PMIPv6: using single unique prefix per MN method or unique prefix per each interface of MN method. "OSPF Transport Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 25-Sep-08, OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. "Session Initiation Protocol Service Example -- Music on Hold", Dale Worley, 28-Aug-08, The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is where, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully effective and standards-compliant, but is simpler than the methods previously documented. "SMTP Service Extension for Indicating Message Authentication Status", Murray Kucherawy, 29-Sep-08, This memo defines an extension to the Simple Mail Transfer protocol (SMTP) service whereby a server can indicate its ability to accept and apply information regarding the efforts of upstream SMTP servers to establish authenticity of the message via various authentication methods. "Problem Statement and Requirement: Mobile Multicast", Hui Deng, Peng Yang, 13-Jul-08, This document discusses the problem and requirement of multicast solution in the mobile networks. One current issue in mobile multicast solution has been raised and requirements of mobile IPTV on multicast mobility will also be summarized especially for some mechanisms such as the tunneling, service capability and security discussion which is basis of supporting the mobile IPTV applications. "Requirement for Multicast MPLS/BGP VPN Partitioning", Maria Napierala, 24-Jun-08, This document describes a requirement for Multicast IP VPN solutions to allow the same multicast stream to flow simultaneously on multiple inter-PE paths without duplicates being sent to receivers. It is intended that existing and new solutions to MPLS/BGP Multicast IP VPN's will support this requirement. "Load Balancing Fat MPLS Pseudowires", Stewart Bryant, Clarence Filsfils, Ulrich Drafz, 9-Jul-08, Where the payload carried over a pseudowire carries a number of identifiable flows it can in some circumstances be desirable to carry those flows over the equal cost multiple paths that exist in the packet switched network. This draft describes a method of identifying the flows, or flow groups, to the label switched routers by including an additional label in the label stack. "Flow Distribution Rule Language for Multi-Access Nodes", Conny Larsson, Michael Eriksson, Koshiro Mitsuya, Kazuyuki Tasaka, Romain Kuntz, 14-Jul-08, This document defines an OS independent rule language as a mean to define and perform per flow path selection for a multi-homed node. Per flow path selection is typically needed when there exist multiple network interfaces, each with different network characteristics, and an application has specific performance requirements for a data flow that makes one network interface more suitable than another. The flow distribution rule set is used by the node itself but also exchanged with other nodes that needs to know about the multi-homed node's capability of receiving data on multiple network interfaces. This document does not define how the rule set is transferred between nodes. "Media Control Channel Framework (CFW) Call Flow Examples", Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Simon Romano, 27-Jun-08, This document provides with a list of more or less detailed Media Control Channel Framework [I-D.ietf-mediactrl-sip-control-framework] call flows. It aims at being a simple guide throughout the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a hopefully helpful base reference documentation for both implementors and protocol researchers. "MVPN Profiles Using PIM Control Plane", A Boers, Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 3-Jul-08, The MVPN (Multicast Virtual Private Network) architecture is divided into a number of functional "layers". At each layer, multiple options are allowed. It is necessary to allow multiple options at each layer because "one size doesn't fit all." However, it is not expected that any particular implementation will support all the possible combinations of options. To ensure multi-vendor interoperability, it is useful to specify "profiles", where each profile is a particular combination of options. The number of specified profiles will be much less than the total number of possible combination, and a given implementation can be characterized by saying which profiles it supports. This document describes two profiles that use a PIM control plane. "Guidelines for firewall administrators regarding MIPv6 traffic", Suresh Krishnan, Niklas Steinleitner, QIU Ying, Gabor Bajko, 30-Apr-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, 30-Apr-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", Dave Thaler, Suresh Krishnan, James Hoagland, 14-Jul-08, The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backwards compatible. "End-Host Authentication for HIP Middleboxes", Tobias Heer, Klaus Wehrle, Miika Komu, 7-Jul-08, The Host Identity Protocol [RFC2119]is a signaling protocol for secure communication, mobility, and multihoming by introducing a cryptographic namespace. This document specifies an extension for HIP that enables middleboxes to unambiguously verify the identities of hosts that communicate across them. This extension enables middleboxes to verify the liveness and freshness of a HIP association and, thus, enables reliable and secure access control in middleboxes. "An HTTPS Location Dereferencing Protocol Using HELD", James Winterbottom, Hannes Tschofenig, Henning Schulzrinne, Martin Thomson, Martin Dawson, 14-Jul-08, This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference into a Presence Information Data Format Location Object (PIDF-LO). The document assumes that a Location Recipient possesses a secure HELD URI that can be used in conjunction with the HELD protocol to request the location of the Target. "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), BGP Community Extension", Jeffrey Haas, 24-Jun-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol's Community extension. "Representation of Uncertainty and Confidence in PIDF-LO", Martin Thomson, James Winterbottom, 4-Jun-08, The key concepts of uncertainty and confidence as they pertain to location information are defined. A form for the representation of confidence in Presence Information Data Format - Location Object (PIDF-LO) is described, optionally including the form of the uncertainty. Suggested methods for the manipulation of location estimates that include uncertainty information are outlined. "Proxy Mutual Authentication in SIP", Steve Dotson, Stuart Hoggan, Sumanth Channabasappa, 10-Jun-08, This document defines the Proxy-Authentication-Info header field for the Session Initiation Protocol (SIP). When a UA is required to authenticate to a proxy using digest authentication specified in SIP this header field allows for the UA to authenticate the proxy, enabling mutual authentication. This header field can also provide integrity checks over the bodies. "What Makes For a Successful Protocol?", Dave Thaler, Bernard Aboba, 27-May-08, The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. "DTLS-SRTP Key Transport", Dan Wing, 14-Jul-08, The existing DTLS-SRTP specification allows SRTP keys to be established between a pair of SRTP endpoints. However, when there are more than two participants in an RTP session, DTLS-SRTP is unable to provide a single key for all of the participants. This existing limitation of DTLS-SRTP prevents deploying DTLS-SRTP in certain scenarios. This document describes an extension to DTLS-SRTP, called Key Transport (KTR). This extension transports SRTP keying material from one DTLS-SRTP peer to another, so the same SRTP keying material can be used by multiple DTLS-SRTP peers. This extension eliminates the need to key each SRTP session individually, allowing cost-effective deployment of several DTLS-SRTP scenarios. "Multicast tunneling optimization for Mobile IPv6", Peng Yang, 14-Jul-08, This document provides the solution to optimize the multicast tunneling in mobile IPv6. This solution will not break the basic bi- directional tunneling multicast solution of MIPv6. A new Mobile Multicast Agent works as a proxy node for multiple mobile nodes within one limit scope. Single tunnel is set up between one Home Agent and one Mobile Multicast Agent for single multicast stream. A new notification message is created for the communication between home agent and mobile multicast agent. There is no modification on mobile nodes. "On Mobile IPv6 Optimization and Multihoming", Chan-Wah Ng, Keigo Aso, 8-Jul-08, This memo explores the possible areas of extensions to MIPv6 route optimization in the considerations of multihomed nodes. The intention is to raise awareness in the research community, leading to a possible extension to RFC 4651. "Multiple Interface Support with Proxy Mobile IPv6", Vijay Devarapalli, Nishi Kant, Heeseon Lim, Christian Vogt, 22-Aug-08, Proxy Mobile IPv6 enables network-based mobility for a regular IPv6 mobile node with no mobility management protocol. It makes it appear to the mobile node that its IP address does not change as the mobile node moves across the Proxy Mobile IPv6 domain. There have been some issues identified with supporting a host with multiple interfaces attaching to the Proxy Mobile IPv6 domain. This document describes and analyzes some of the scenarios associated with this. "Multi-homing in BGP-based Virtual Private LAN Service", Kireeti Kompella, Bhupesh Kothari, Thomas Spencer IV, 12-Jul-08, Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how multi-homing can be offered in the context of BGP-based VPLS. "Performance Evaluation of PCN-Based Algorithms", Michael Menth, Frank Lehrieder, 4-Jul-08, This document presents a summary of performance studies for PCN-based admission control and flow termination. The numerical results were obtained by simulation or mathematical analysis. "IANA Registration for Encrypted ENUM", Ben Timms, Jim Reid, Jakob Schlyter, 12-Jul-08, This document requests IANA registration of the "X-Crypto" Enumservice. This Enumservice indicates that its NAPTR holds a Uniform Resource Identifier that carries encrypted content from the fields of another (unpublished) Protected NAPTR, for use in E.164 Number Mapping (ENUM). "Mutual Authentication Protocol for HTTP", Yutaka Oiwa, 11-Aug-08, This document specifies the "Mutual authentication protocol for Hyper-Text Transport Protocol". This protocol provides true mutual authentication between HTTP clients and servers using simple password-based authentication. Unlike Basic and Digest HTTP access authentication protocol, the protocol ensures that server knows the user's entity (encrypted password) upon successful authentication. This prevents common phishing attacks: phishing attackers cannot convince users that the user has been authenticated to the genuine website. Furthermore, even when a user has been authenticated against an illegitimate server, the server cannot gain any bit of information about user's passwords. The protocol is designed as an extension to the HTTP protocol, and the protocol design intends to replace existing authentication mechanism such as Basic/Digest access authentications and form-based authentications. "IGMP/MLD Error Feedback", Thomas Morin, Brian Haberman, 11-Jul-08, This document describes messages and procedures that can optionally be implemented in IGMP/MLD Queriers and Hosts, to provide information to multicast receivers on the reason why the IGMP/MLD Querier didn't take into account a Membership Report message. "The Zone Status (ZS) DNS Resource Record", Jim Reid, 4-Jul-08, A Domain Name System (DNS) resource record which provides status information about a zone is described in this document. "Rogue IPv6 Router Advertisement Problem Statement", Tim Chown, Stig Venaas, 14-Jul-08, 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, 14-Jul-08, IPFIX supports the concept of a Mediator, a device that receives, transforms, and exports data streams using IPFIX. One of the most important requirements is the reduction of the volume of IPFIX traffic by aggregating and discarding received information. This document introduces a number of extensions to the IPFIX Information Model that support the export of aggregated IPFIX data, introducing abstract data types and Information Elements that optimize the transport of descriptive information in terms of flow records' amount and size. All extensions are directly applicable to the IPFIX Mediator but can be used in many different applications as well. "MPLS and Ethernet OAM Interworking", Dinesh Mohan, Nabil Bitar, Simon Delord, Philippe Niger, 8-Jul-08, This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet Pseudowires (PWs) connected in accordance to the PWE3 architecture [RFC3985] to realize an end-to-end emulated Ethernet service. This document augments the mapping of defect states between a PW and associated AC of the end-to-end emulated service in [PW-OAM-MSG- MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack of Ethernet OAM maturity. However, since then, [Y.1731] and[802.1ag] have been completed, and this document specifies the mapping of defect states between Ethernet ACs and corresponding Ethernet PWs. "Problem Statement: Transport Protocols Don't Have To Do Fairness", Bob Briscoe, T Moncaster, Anne-Louise Burness, 14-Jul-08, The Internet is an amazing achievement - any of the thousand million hosts can freely use any of the resources anywhere on the public network. At least that was the original theory. Recently issues with how these resources are shared among these hosts have come to the fore. Applications are innocently exploring the limits of protocol design to get larger shares of available bandwidth. Increasingly we are seeing ISPs imposing restrictions on heavier usage in order to try to preserve the level of service they can offer to lighter customers. We believe that these are symptoms of an underlying problem: fair resource sharing is an issue that can only be resolved at run-time, but for years attempts have been made to solve it at design time. In this document we show that fairness is not the preserve of transport protocols, rather the design of such protocols should be such that fairness can be controlled between users and ISPs at run-time. "Network Scaling with Aggregate LSPs", George Swallow, Jim Guichard, Intellectual Property, 7-Jul-08, This document defines a means for an Multiprotocol Label Switched network to summarize routes while maintaining end-to-end LSP connectivity thereby reducing the number of host routes that need to be carried within the interior gateway protocol.Contents "LISP Alternative Topology (LISP+ALT)", Dino Farinacci, 24-Apr-08, This document describes a method of building an alternative, logical topology for managing Endpoint Identifier to Routing Locator mappings using the Locator/ID Separation Protocol. The logical network is built as an overlay on the public Internet using existing technologies and tools, specifically the Border Gateway Protocol and the Generic Routing Encapsulation. An important design goal for LISP+ALT is to allow for the relatively easy deployment of an efficient mapping system while minimizing changes to existing hardware and software. "Point-to-Multipoint Pseudowire Signaling and Auto-Discovery in Layer 2 VPNs", Rahul Aggarwal, 13-Jul-08, A Point-to-Multipoint (P2MP) Pseudo Wire (PW) is a mechanism that emulates the essential attributes of a unidirectional P2MP Telecommunications service such as P2MP ATM over a Packet Switched Network (PSN). [RFC4664] describes a number of different ways in which sets of PWs may be combined together into "Provider Provisioned Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different kinds of L2VPN. P2MP PWs enable a L2VPN to provide a Virtual Private P2MP unidirectional service (VPMS), which may be in addition to the Virtual Private Wire Service (VPWS) offered by the L2VPN. This document describes how procedures outlined in [VPLS-MCAST] can be used to signal P2MP PWs and enable a P2MP unidirectional service in a L2VPN. "VPLS OAM", Dinesh Mohan, Ali Sajassi, Deborah Brungard, Henry Fowler, Simon Delord, Philippe Niger, 12-Jul-08, This document provides a comprehensive end-to-end solution for VPLS Operation, Administration and Maintenance (OAM). This solution is based on the L2VPN OAM framework [L2VPN-OAM-REQ-FRMK] and specifies how to meet the requirements set therein. "BGP protocol extensions using attribute for Path Computation Element (PCE) Discovery", Kenji Kumaki, Tomoki Murai, 17-Apr-08, It is highly desirable for Path Computation Clients (PCCs) to be able to dynamically discover a set of Path Computation Elements (PCEs) when PCCs/PCEs request a path computation to PCEs within an AS and across ASs. In such a scenario, specifically BGP/MPLS IP-VPNs, it is advantageous to use BGP to distribute PCE information. This document defines a new attribute and describes how PCE information can be carried using BGP. "RTP Payload Format for MVC Video", Ye-Kui Wang, Thomas Schierl, 21-Aug-08, This memo describes an RTP payload format for the multiview extension of the ITU-T Recommendation H.264 video codec that is technically identical to ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units, produced by the video encoder, in each RTP payload. The payload format has wide applicability, such as 3D video streaming, free-viewpoint video, and 3DTV. "IGMP and MLD Extensions for Mobile Hosts and Routers", Hitoshi Asaeda, Thomas Schmidt, 14-Jul-08, This document describes IGMP and MLD protocol extensions for mobile hosts and routers. IGMP and MLD are necessary protocols for hosts to request join or leave multicast sessions. While the regular IGMP and MLD protocols support communication between mobile hosts and routers over wireless networks, this document discusses the conditions how mobile hosts and routers use IGMP and MLD in their communication more effectively. Aside from a modified protocol semantic, an optional "Listener Hold" function for the IGMP and MLD protocol is introduced, which requires an extended signaling. "Camellia Counter mode and Camellia Counter with CBC Mac mode algorithms", Akihiro Kato, Masayuki Kanda, 16-Sep-08, This document describes the algorithms and test vectors of Camellia block cipher algorithm in Counter mode and Counter with Cipher Block Chaining MAC mode. The purpose of this document is to make the Camellia-CTR and Camellia-CCM algorithm conveniently available to the Internet Community. "A Session Description Protocol (SDP) Control Package Attribute", Chris Boulton, 20-Aug-08, This document defines a new Session Description Protocol (SDP) media- level attribute: "ctrl-package". The "ctrl-package" attribute conveys details of the SIP Control Framework extension packages that are supported by a client participating in an offer/answer exchange. "RTP payload format for G.718 speech/audio", Ari Lakaniemi, Ye-Kui Wang, 7-Oct-08, This document specifies the Real-Time Transport Protocol (RTP) payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/audio codec, specified in ITU-T G.718. A media type registration for this RTP payload format is also included. "Providing guidance for Session Initiation Protocol (SIP) services", Arnaud Ligot, Thomas Froment, 11-Jul-08, Implementing Session Initiation Protocol (SIP) advanced features and services requires to use numerous specifications. Today, for each service in the scope of BLISS, one can already find references to many possible specifications which do not cover the same things. Some of them are primitive operations, requirements or call flow examples, some have a scope larger than the others, or can not be compared at the same level. Very often, architecture hypothesis are hidden behind the same service name, either assuming that an intermediary; like an application server, has an active role in the service, or, as opposed, assuming a pure end-to-end model where only endpoint implementations are involved. The goal of this document is not to present the best solutions or give recommendations; but to give an overview of every standard specification related to these services, centralizing and categorizing them as input to the working group. "Service Identfiers Option for DHCPv6", Hui Deng, Hong Liu, Bernie Volz, 13-Jul-08, This document describes a new option for DHCPv6 [RFC3315] that provides a mechanism for specifying a list of service identifer which this connection support or don't support. "Verification of Care-of Addresses in Multiple Bindings Registration", Benjamin Lim, Chan-Wah Ng, Keigo Aso, Suresh Krishnan, 10-Jul-08, Using multiple care-of address registration, there is a possibility that a malicious mobile node could create multiple care-of address bindings that does not belong to the mobile node at its home agent. The home agent would accept these bindings without verifying them due to the trust relationship it has with the mobile node. With these bindings, the mobile node can launch attacks by asking the home agent to flood the victims of these care-of addresses with useless packets. To mitigate such a problem, this memo introduces a few possible verification mechanisms that the home agent would use in order to verify the care-of addresses for the mobile node before using them for packet routing. "An Explicit Signaling Target Message Routing Method (EST-MRM) for the General Internet Signaling Transport (GIST) Protocol", Roland Bless, 8-Jul-08, The standard operation of the General Internet Signaling Transport (GIST) Protocol uses a path-coupled message routing method (PC-MRM) to find nodes interested in signaling message exchanges. This specification proposes an Explicit Signaling Target Message Routing Method (EST-MRM) in order to allow sending of signaling messages to explicit targets. "Reporting of DKIM Verification Failures", Murray Kucherawy, 10-Jul-08, This memo presents an extension to the DomainKeys Identified Mail (DKIM) specifications to allow public keys for verification to include a reporting address to be used to report message verification issues, and extends an Internet Message reporting format to be followed when generating such reports. "Roaming Mechanism between PMIPv6 Domains", Jee-Hyeon Na, Soochang Park, Jung-Mo Moon, Sangho Lee, Euisin Lee, Sang-Ha Kim, 10-Jul-08, Proxy Mobile IPv6 (PMIPv6) is designed to provide mobility service to mobile nodes in the network domain which does not require the mobile nodes to be involved in IP mobility management. In other words, the PMIPv6 can transparently support roaming within a PMIPv6 domain, i.e. intra-domain roaming, to mobile nodes. However, if the mobile nodes move to other PMIPv6 domains, the nodes should have additional protocols for the inter-domain roaming although the domains also provide the transparent mobility. Hence, an inter-domain roaming solution would be needed for providing transparent mobility to mobile nodes that only move around among PMIPv6 domains. This document specifies the inter-domain roaming controlled by the networks adopting the PMIPv6. "DHCP Segmentation/Reassembly using SEAL", Fred Templin, 30-Jul-08, IP fragmentation has been shown to be problematic through operational experience and through studies conducted over the course of many years. Some transports (e.g., TCP) have the abilitiy to adjust their message sizes to avoid IP fragmentation, however no such capability is built into the UDP transport. UDP applications such as DHCP must therefore have a means to perform their own segmentation prior to submitting their data to UDP/IP in order to avoid IP fragmentation. This document specifies a segmentation/reassembly capability for DHCP using SEAL. "An overload control package for the Session Initiation Protocol (SIP).", Youssef Chadli, Xavier Marjou, 11-Jul-08, This document specifies an event package for the notification of overload control using the Session Initiation Protocol (SIP) events framework. The overload control package allows an upstream server to retrieve overload control information from a downstream server and to be notified when this information changes. This information is used by the upstream server to adapt its flow toward the downstream server and thus to avoid overloading it. "UDP Traceroute Message Extension", Naiming Shen, Carlos Pignataro, Rajiv Asati, Enke Chen, 7-Jun-08, This document specifies an extension to UDP traceroute messages that allows the UDP traceroute probe packets to be authenticated by the intermediate nodes and the destination node. This extension can also include requests for node specific information that the sender is interested to receive from one or more nodes via the traceroute replies. "Proactive Bindings for FMIPv6", Faqir Yousaf, Christian Wietfeld, 14-Jul-08, Usually in FMIPv6, the MN will start the binding process with its home agent and the correspondent nodes after it has attached to NAR. Till the binding is completed, the mobile node continues to receive packets via a reverse tunnel established between PAR and NAR. The duration of this tunnel will depend on the time it takes for the mobile node to complete its binding, till which time the tunnel will continue to consume buffer and processing resources related to maintaining the tunnel and forwarding packets through this tunnel in both PAR and NAR. This document specifies an extension to FMIPv6 to enhance its performance, in terms of resource management, by reducing the duration of the tunnel existence. This is achieved by enabling the NAR to act as a proxy for the MN for FMIPv6 handover. Additional message(s) and message options along with modifications to existing FMIPv6 messages and message options and definitions of new messages and message options to achieve the desired functionality is also described in this document. "Diagnose P2PSIP Overlay Network Failures", Song Yongchao, Hewen Zhang, XingFeng Jiang, 6-Jul-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 "Echo request" message and "Echo response" message for the purpose of fault detection and localization, and mechanisms for processing those messages. "Interworking LISP with IPv4 and IPv6", Darrel Lewis, Dave Meyer, Dino Farinacci, Vince Fuller, 11-Jul-08, This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP [LISP]) to interoperate with Internet sites not running LISP. A fundamental property of LISP- speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IP addresses, routes for them are not carried in the global routing system so an interoperability mechanism is needed for non-LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces two such mechanisms: the first uses a new network element, the LISP Proxy Tunnel Router (PTR) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts while the second adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. "Clearance and CA Clearance Constraints Certificate Extensions", Sean Turner, Santosh Chokhani, 14-Jul-08, 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. "Specifying Location Quality Constraints in Location Protocols", Martin Thomson, James Winterbottom, 26-May-08, Parameters that define the expected quality of location information are defined for use in location protocols. These parameter can be used by a requester to indicate to a Location Server the desired constraints on the quality of the location information provided. If applicable, the Location Server is able to use this information to control how location information is determined. An optional indication of whether the quality constraints were met is defined to be provided by the Location Server alongside location information. "Other Certificates Extension", Stephen Farrell, 8-Jul-08, Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates belonging to the same end entity that can safely be considered to be equivalent for the purposes of referencing that application state information. This memo defines a certificate extension that supports such linkage that can allow applications to establish the required linkage without introducing a new application protocol data unit. "Translator specification approach", Hiroshi Miyata, 14-May-08, 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. "L2TPv3 Extended Circuit Status Values", Neil McGill, Carlos Pignataro, 25-Jun-08, This document defines additional Layer 2 Tunneling Protocol Version 3 (L2TPv3) bit values to be used within the "Circuit Status" Attribute Value Pair (AVP) to communicate more granular error states for Access Circuits and Pseudowires. It also deprecates the use of the New bit in the "Circuit Status" AVP, updating RFC3931. "XESP for Traffic Visibility", Ken Grewal, 23-Jun-08, This document describes an ESP encapsulation for IPsec, allowing intermediate devices to ascertain if ESP-NULL is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 5-Aug-08, This document defines a bi-directional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat", Peter Saint-Andre, Eddy Gavita, Nazin Hossain, Salvatore Loreto, 10-Jul-08, This document defines a bi-directional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). "On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship", Wassim Haddad, Mats Naslund, 13-Jul-08, This document introduces a simple mechanism which enables a host using IPv6 cryptographically generated address to delegate the task of secure neighbor discovery proxying to another node by means of establishing a "symbiotic" relationship with that node. "On Using 'Symbiotic Relationship' to Repel Network Flooding Attack", Wassim Haddad, Mats Naslund, 14-Jul-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, 5-Aug-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. "Syntax for binding documents with time stamps", Adriano Santoni, 10-Jun-08, This document describes a syntax which can be used to bind a generic document (or any set of data, not necessarily protected by means of cryptographic techniques) to one or more time-stamp tokens obtained for that document, where "time-stamp token" has the meaning defined in RFC 3161. Additional types of temporal evidence are also supported. Santoni Expires December 10, 2008 [page 1] Internet-Draft timestampeddata June 2008 This document proposes a simple syntax based on the Cryptographic Message Syntax (RFC 3852). "SNMP Trace Analysis Definitions", University Twente, Aiko Pras, Matus Harvan, 23-Apr-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", Luca Martini, Philippe Niger, Yaakov Stein, Frederic JOUNAY, Matthew Bocci, Simon DeLord, 22-Sep-08, The dynamic End-to-End Multisegment pseudowire setup requires PEs to maintain a pseudowire routing table when using FEC129. There is a requirement to automatically advertise Attachment Individual Identifiers to enable the pseudowire routing tables to be populated. Two mechanisms already exist, a BGP reachability information distribution mechanism and an IGP based one. Here we define a third solution relying on LDP. It allows for automatic advertisement of the Attachment Individual Identifier prefixes provisioned on a T-PE when this node does not run BGP or IGP. The mechanism described here runs on the T-LDP (Targeted LDP) session between the T-PE and S-PE, and is intended to complement existing PW routing mechanisms using BGP or OSPF. "Extensible Supply-chain Discovery Service Problem Statement", Ali Rezafard, 1-Sep-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-01". Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", Paul Hoffman, 24-Jun-08, This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. "Digital Signatures on Internet-Draft Documents", Russ Housley, 21-Aug-08, This document specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. "Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP)", Salvatore Loreto, 14-Jul-08, This document registers with IANA two new DNS SRV Protocol Labels for resolving Instant Messaging and Presence services with SIP. "Connecting IPv6 Islands over IPv4 MPLS networks using IPv6 Provider Edge Routers (6PE-Alt)", Vishwas Manral, 4-Sep-08, This document provides an alternate mechanism to [6PE] to interconnect IPv6 routes over MPLS-enabled IPv4clouds. This approach relies on IPv6 Provider Edge routers (6PE-Alt) which are Dual Stack in order to connect to IPv6 islands and to the MPLS core which is only required to run IPv4 MPLS and run the mechanism as described in this document. The 6PE-Alt routers exchange the IPv6 reachability information transparently over the core using the Multi-Protocol Border Gateway Protocol (MP-BGP) over IPv4 or IPv6. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE-Alt router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. Unlike [6PE] case the labels are not sent with each route and does not use BGP to transport labels [RFC3107]. It instead makes use of the IPv6 Explicit NULL label as the VPN label, which is defined [RFC3032] and updated in [RFC4182]. This document elegantly uses the concept of non overlapping IPv6 routes to provide BGP MPLS IP VPN functionality. The document can be further used for provinding the functionality in case of non-overlapping IPv6 routes. This approach allows a functionality similar to [RFC4659], without the cumbursome extensions required for the same. With the [RFC3879] IPv6 addresses are now globally unique (except for Link local). It also reduces the number of multi AS scenarios. "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", Nikos Mavrogiannopoulos, 4-Aug-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, Apoorva Karan, A Boers, Maria Napierala, 21-May-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, Masahito Endo, 29-Sep-08, This document specifies an IPv4-to-IPv6 transition mechanism to provide accessibility for IPv6 node to IPv4 node, and vice-versa. The goal of this document is not providing the most fundamental technology which could works well with additional technology. We used to have an technology called NAT-PT[RFC2766]. NAT-PT was designed to work with problematic DNS Application Level Gateway. So, it was changed to historical state by [RFC4966]. This document attempts to simplify NAT-PT specification, removing dependability on Application Layer Gateway as well as resolving problems pointed in [RFC4966]. "Shim6 Implementation Report : LinShim6", Sebastien Barre, 11-Jul-08, LinShim6 is an implementation of the Shim6 and REAP protocols, on the Linux platform. This draft provides a description of the architecture and describes the current state of our implementation. The level of support of each protocol feature is detailed. Protocol conformance is evaluated against the main drafts. "Special Use IPv4 Addresses", Michelle Cotton, 2-Jun-08, This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. Special IPv6 addresses are described in RFC 5156. "Indicating Support for Basic Media Server Capabilities in the Session Initiation Protocol (SIP)", Chris Boulton, 20-Aug-08, This specification defines a profile set of media feature tags that can be used with the Session Initiation Protocol (SIP). The media feature tags allow a Media Server to communicate a basic set of media server capabilities that are supported to its Application Server. "EAP Authentication Using Only A Password", Dan Harkins, Glen Zorn, 23-Jun-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. "IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", Remi Despres, 10-May-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). "IMAP Response Codes", Arnt Gulbrandsen, 16-Apr-08, IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code and a human-readable text. This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting.1. Conventions Used in This Document Formal syntax is defined by [RFC5234] as modified by [RFC3501]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. "[...]" means elision. "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Fred Templin, 19-Aug-08, For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulated border nodes. These virtual topologies may span multiple IP- and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. "XCAST6 (version 2.0) Protocol Specification", Yuji Imai, Takahiro Kurosawa, Nobuo Kawaguchi, Eiichi Muramoto, 17-Aug-08, This document describes the specification of Xcast6 (Explicit Multi- unicast (Xcast) for IPv6), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. The difference from the experimental specification which is described in [5058] is that this version eliminates Hop-by-Hop header which sometimes suffers hardware router. "Specification of 3GPP IM CN Subsystem XML body handling", John-Luc Bakker, 8-Aug-08, This document registers new disposition-types for the Content- Disposition header that apply to the application/3gpp-ims+xml body used by 3GPP. The applicability of these content-disposition values are limited to 3GPP IMS. The application/3gpp-ims+xml body has the following two distinct uses: (1) for redirecting the emergency session to use a different domain (e.g. using a Circuit Switched call), and (2) for delivering user profile specific information from the SIP registrar to an Application Server. "A Binary Floor Control Protocol (BFCP) Control Package for the Media Control Channel Framework", Lorenzo Miniero, Simon Romano, Roni Even, Scott McGlashan, 8-Jul-08, This document defines a Media Control Channel Framework Package for BFCP-based conference moderation. The control of Media Servers and their related resources in decomposed network architectures plays an important role in various Next Generation Networks. This Control Package aims at adding BFCP functionality to conferences using the Media Control Channel Framework. "Enabling an Enhanced Care-of Address Reachability Test for the Home Agent", Wassim Haddad, Francis Dupont, 14-Jul-08, This memo aims to improve Mobile IPv6 protocol security by enabling an enhanced care-of address rechability test for the home agent. The main goals are to discourage a rogue mobile node from misleading its home agent to flood a targeted foreign network and to empower the latter to thwart this type of attack if launched at a later stage. "PIM Group-to-RP Mapping", Bharat Joshi, Andy Kessler, David McWalter, 11-Jun-08, Each PIM-SM router in a PIM Domain which supports ASM maintains Group-to-RP mappings which are used to identify a RP for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not allow administrator to override a specific Group-to-RP mapping with the static Group-to-RP mapping which an administrator would want to use. This algorithm also does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. "Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-NAT)", Thomas Phelan, 10-Jul-08, This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-NAT. This encapsulation will allow DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. "More Features for TWAMP", Al Morton, Kaynam Hedayat, 13-Jul-08, The IETF is completing its work on TWAMP - the Two-Way Active Measurement Protocol. This memo describes additional features for TWAMP, essentially the ability to use different security modes in the TWAMP-Control and TWAMP-Test protocols. "RTP Payload Format for H.264 Video", Ye-Kui Wang, Stephan Wenger, Miska Hannuksela, Thomas Stockhammer, Magnus Westerlund, David Singer, 14-Jul-08, This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit- rate video-on-demand. This memo intends to obsolete RFC 3984. "Home Automation Routing Requirement in Low Power and Lossy Networks", A Brandt, 13-May-08, This document presents home control and automation application specific requirements for ROuting in Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include lighting control, heating control, sensors, leak detectors, healthcare systems and advanced remote controls. Because such devices only cover a limited radio range, multi-hop routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home network environment. "Guidelines for Usage of Interactive Connectivity Establishment (ICE) by non Session Initiation Protocol (SIP) Protocols", Jonathan Rosenberg, 14-Jul-08, Interative Connectivity Establishment (ICE) has been specified as a NAT traversal mechanism for protocols based on the offer/answer exchange model. In practice, only the Session Initiation Protocol (SIP) has used ICE. This document provides guidance on how other protocols can make use of ICE. "Session Based Trivial Object Transfer and Exchange (TOTE)", Jonathan Rosenberg, 14-Jul-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. "Litmus Tests for Usage of the Session Initiation Protocol (SIP) INFO Method", Jonathan Rosenberg, 14-Jul-08, The Session Initiation Protocol (SIP) Working Group is considering the standardization of a framework for conveying application data through the INFO method. However, the INFO method is just one of several techniques available in SIP for the transfer of application data. Others include through the SIP events framework and through a media session. This document provides guidelines and litmus tests for determining which is the right technique to use. "DHCPv4 Leasequery by relay agent remote ID", Pavan Kurapati, D.T.V. Ramakrishna Rao, Bharat Joshi, 16-Jun-08, Some Relay Agents extract lease information from the DHCP message exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing, prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server as and when this information is lost. Existing leasequery mechanism is data driven which means that a relay agent can initiate the leasequery only when it starts receiving data from/to the clients. In certain scenarios, this model is not scalable. This document first looks at issues in existing mechanism and then proposes a new query type, query by remote ID, to address these issues. "ILNP Concept of Operations", Randall Atkinson, 11-Jun-08, This documents the Concept of Operations for an experimental extension to IPv6 which is known as the Identifier Locator Network Protocol (ILNP). "A Profile for Bogon Origin Attestations (BOAs)", Geoff Huston, Terry Manderson, George Michaelson, 21-Apr-08, This document defines a standard profile for Bogon Origin Attestations (BOAs). A BOA is a digitally signed object that provides a means of verifying that an IP address block holder has not authorized any Autonomous System (AS) to originate routes that are equivalent to any of the addresses listed in the BOA, 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 measures to inter-domain routing, including the ability to support incremental and piecemeal deployment of such measures, and does not require any changes to the specification of BGP. "Conventions for the Use of the Session Description Protocol (SDP) for Circuit-Switched Bearer Connections in the Public Switched Telephone Network (PSTN)", Miguel Garcia-Martin, Simo Veikkolainen, 15-Apr-08, This memo describes use cases, requirements, and protocol conventions for using the Session Description Protocol (SDP) Offer/Answer model for establishing circuit-switched bearer connections in the Public Switched Telephone Network (PSTN). Additionally, this memo proposes conventions for using SDP and the SDP capability negotiation framework for expressing those circuit-switched bearer connections as alternatives to packet-switched streams. "Updates to LDP for IPv6", Vishwas Manral, Rajiv Papneja, 4-Sep-08, LDP is defined in [RFC5036]. LDP (for Label Distribution Protocol) defines procedures for LSRs to distribute labels to support MPLS forwarding along normally routed paths. LDP is a protocol defined for distributing labels. It is the set of procedures and messages by which Label Switched Routers (LSRs) establish Label Switched Paths (LSPs) through a network by mapping network-layer routing information directly to data-link layer switched paths. These LSPs may have an endpoint at a directly attached neighbor (comparable to IP hop-by-hop forwarding), or may have an endpoint at a network egress node, enabling switching via all intermediary nodes. The LDP procedures are defined for both IPv4 and IPv6 networks. This document corrects and clarifies the LDP behavior for IPv6 networks as defined in [RFC5036] for helping in better interoperability between implementations. "TraceFlow", Arun Viswanathan, Subi Krishnamurthy, Rajeev Manur, Vishal Zinjuvadia, 16-Aug-08, This document describes a new OAM protocol - TraceFlow that captures information pertaining to a traffic flow along the path that the flow takes through the network. TraceFlow is ECMP and link-aggregation aware and captures the information about constituent members through which the traffic flow passes. TraceFlow gathers information that is relevant to the flow such as interface address, interface statistics, effect of network policies on the flow and so on. "SCTP-Based Media Transport in the Session Description Protocol.", Salvatore Loreto, Gonzalo Camarillo, 14-Jul-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. "Locater ID proposal evaluation", Anne-Louise Burness, Philip Eardley, Luigi Iannone, 14-Jul-08, There are many proposals for improving the Inter-domain routing system, most of which involve a form of locater-identity split. There needs to be a means to reason about the strengths of the different proposals against the design criteria, and without requiring large scale implementations. This document aims to start this process by drawing parallels with existing systems. It identifies a number of questions that need to be more fully thought about whilst we press ahead with system development. "Usecases and Benefits of end to end ECN support in PCN Domains", Zaheduzzaman Sarker, Ingemar Johansson, 20-May-08, This document provides an informative overview of possible use cases where ECN marking can be used for inelastic traffic. It outlines benefits of preserving the ECN support in a PCN domain. As ECN provides with a simple mechanism for network nodes to inform the end points about possible upcoming congestion and resulting packet losses and delay increase, the scheme can be useful for adaptive real-time media applications, thus enabling them to adjust the transmission rate to avoid quality degradation due to congestion. By showing the benefits of ECN this memo asks the working group to consider end to end ECN support in PCN domain. "OpenLISP Implementation Report", Luigi Iannone, Damien Saucez, Olivier Bonaventure, 16-Jul-08, The RRG is working on the design of an alternate Internet Architecture in order solve issues of the current architecture related to scalability, mobility, multi-homing, and inter-domain routing. Among the various proposals, LISP (Locator/ID Separation Protocol) is one of the most advanced. The present draft describes the overall architecture of OpenLISP, an open source implementation of the LISP proposal. Further, the draft contains some general remarks concerning the design and the implementation of the LISP protocol. "HIP Certificates", Tobias Heer, Samu Varjonen, 14-Jul-08, This document specifies a certificate parameter called CERT for the Host Identity Protocol (HIP). The CERT parameter is a container for Simple Public Key Infrastructure (SPKI) and X.509.v3 certificates. It is used for carrying these certificates in HIP control messages. Additionally, this document specifies the representations of Host Identity Tags in SPKI and X.509.v3 certificates. "Mobile IPv6 Residual Threats", Wassim Haddad, George Tsirtsis, Benjamin Lim, Suresh Krishnan, Francis Dupont, 14-Jul-08, This memo aims to highlight specific "residual" threats in Mobile IPv6 protocol. We call these threats "residual" simply because they were rightfully deemed not urgent during the design of Mobile IPv6 protocol. However, these threats are somehow benefiting from new mechanisms and/or extensions built on top of Mobile IPv6 protocol to improve their effects and likelihood. Hence, our main goal is to motivate designers to re-assess their potential taking into consideration these new mechanisms. "The Session Initiation Protocol (SIP) P-Private-Network-Indication Private-Header (P-Header)", Hans Erik van Elburg, Keith Drage, 11-Jul-08, This document describes why a private network indication is needed. A private network indication allows other nodes in a network to treat private network traffic to a different set of rules then public network traffic. The indication also distinguishes one private network from another private network. "Softwires Network Address Translation (SNAT)", Ralph Droms, Brian Haberman, 14-Jul-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, 14-Jul-08, This document outlines scenarios in which legitimate SIP traffic may appear similar to traffic associated with voice spam, also known as "SPIT" or "Spam for Internet Telephony. This document is created to provide input into the current discussions about how best to address the issue of SPIT. "Diameter ITU-T Rw Policy Enforcement Interface Application", Dong Sun, 14-Jul-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). "The Uniform Resource Identifier (URI) DNS Resource Record", Patrik Faltstrom, Olaf Kolkman, 13-Jul-08, This document defines a new DNS resource record, called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs. "Simultaneous Mobility Problem Statement", Daniel Wong, Ashutosh Dutta, Henning Schulzrinne, 10-Jul-08, This document provides a problem statement for simultaneous mobility in an infrastructure-based mobility environment. It considers what the simultaneous mobility problem is and describes the conditions under which it may occur. It also illustrates the occurrence of the simultaneous mobility problem in the context of different mobility protocols such as Mobile IPv6. The simultaneous mobility problem defined here is strictly applied to scenarios when the intermediary nodes in the core are not mobile. "P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP)", Dan York, Tolga Asveren, 11-Jul-08, This document describes 'P-Charge-Info', a private Session Initiation Protocol (SIP) header (P-header) used to convey billing information about the party to be charged. This P-Header is currently in production usage by a number of equipment vendors and carriers and this document is submitted to request the registration of this header with IANA as required by section 4.2 of RFC 3427. "ProxyMIP Extension for Inter-MAG Route Optimization", Ashutosh Dutta, Subir Das, Hidetoshi Yokota, Tsunehiko Chiba, Henning Schulzrinne, 13-Jul-08, This draft describes a light weight route optimization technique that helps to optimize the media path between two communicating nodes when Proxy MIP is used as the mobility protocol. This routing optimization technique is most useful when the two communicating hosts are away from home and need to communicate with each other using an optimized path. It takes advantage of the data packet between LMA and MAG to set up the optimized data path between the communicating hosts. This route optimization technique is applicable to both the intra-LMA and inter-LMA scenarios. "RTP Payload Format for Non-Interleaved and Interleaved Parity FEC", Ali Begen, 11-Sep-08, This document defines new RTP payload formats for the Forward Error Correction (FEC) that is generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP. These parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The non-interleaved and interleaved parity codes offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications. "Provisioning Protocol Requirements for ENUM-SIP Addressing Servers", Tom Creighton, Jean-Francois Mule, 14-Jul-08, This document presents use cases and protocol requirements for provisioning ENUM-SIP addressing servers. The provisioned data is used by the addressing server to return session establishment data for SIP entities to route SIP requests to the target destinations. An ENUM-SIP addressing server acts as a Lookup Function in session peering to determine the target domain of a given SIP request. It may also act as a Location Routing Function to develop the location of the SIP signaling entity in the target domain. "A Provisioning Protocol for ENUM-SIP Addressing Servers", Kenneth Cartwright, Stephen Dimig, Mark Teodoro, Jean-Francois Mule, 14-Jul-08, This document defines a provisioning protocol for ENUM-SIP addressing servers. An ENUM-SIP addressing server is a host that acts as Lookup Function in session peering to determine the target domain of a given SIP request and it may also act as a Location Routing Function to develop the location of the SIP signaling entity in that target domain. This protocol allows SIP service providers to provision and manage session establishment data used by SIP network elements to route SIP sessions to the target destinations which may be served by the SIP service provider's own internal network or by a session peering partner. The data provisioned into an ENUM-SIP addressing server is queried by SIP entities using ENUM or SIP. This version of the protocol integrates comments received on the IETF peppermint and drinks mailing lists before July 2008. This document is an Internet-Draft and the protocol it describes is subject to technical changes that may make this version incompatible with future versions defined in Internet-Drafts. It is expected that the authors will continue to update this protocol based on the drinks working group requirements on the session establishment data. "Guidelines for Extending the RTP Control Protocol (RTCP)", Joerg Ott, Colin Perkins, 15-Jun-08, The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptivity and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient. "Representing Netconf Data Models using Document Schema Definition Languages (DSDL)", Rohan Mahy, Sharon Chisholm, Ladislav Lhotka, 8-Jul-08, This document describes a concrete approach for representing Netconf and other IETF data models using the RelaxNG schema language and the Schematron validation language, which are both part of ISO's Document Schema Definition Languages (DSDL) standard. "Requirements for GMPLS applications of PCE", Tomohiro Otani, Kenichi Ogaki, 14-Jul-08, The initial effort of PCE WG is specifically focused on MPLS (Multi- protocol label switching). As a next step, this draft describes functional requirements for GMPLS (Generalized MPLS) application of PCE (Path computation element). "Routing System Stability", Dimitri Papadimitriou, James Lowe, 29-Jul-08, Understanding the dynamics of the Internet routing system is fundamental to ensure its robustness/stability and to improve the mechanisms of the BGP routing protocol. This documents outlines a program of activity for identifying, documenting and analyzing the dynamic properties of the Internet and its routing system. "Configuring BFD with DHCP and Other Musings", Vitali Vinokour, David Ward, 9-May-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. "Kerberos Option for DHCPv6", Masahiro Ishiyama, Shoichi Sakane, 1-Oct-08, This document defines a new DHCPv6 option to carry a set of configuration information related to the Kerberos protocol [RFC4120]. This document also defines three sub-options to be used in this new option, which specify a realm name of the Kerberos, a list of IP addresses of the Key Distribution Center of that realm and a client principal name to distinguish a Kerberos client by the DHCPv6 server. "Ivip Mapping Database Fast Push", Robin Whittle, 20-Aug-08, Ivip (Internet Vastly Improved Plumbing) is a proposed map-encap system which is intended to provide a solution for the routing scaling problem - supporting growing numbers of end-user networks with multihoming, traffic engineering and portability, without further growth in the global BGP routing table. Ivip is also intended to provide other benefits, including a new form of IPv4 and IPv6 mobility and better utilization of IPv4 address space. To achieve these benefits, Ivip relies on a "fast mapping database push" system, which is required to securely and reliably deliver updates to the mapping database to hundreds of thousands - or potentially millions - of ITRs (Ingress Tunnel Routers) and Query Servers (QSes) all over the Net, ideally within a few seconds. This ID describes the requirements of such a system and how it could be implemented so as to cope with very large numbers of updates and ITR/QS sites. "RBridges: Use of IS-IS", Donald Eastlake 3rd, Radia Perlman, Dinesh Dutt, 4-Aug-08, RBridges implement the TRILL protocol, which in turn makes use of an extended version of the IS-IS (Intermediate System to Intermediate System) routing protocol to determine topology and frame forwarding. RBridges provide optimal pair-wise forwarding with zero configuration, safe forwarding even during periods of temporary loops, and multipathing for both unicast and multicast traffic. Rbridges also support VLANs. This document specifies details of TRILL use of IS-IS. "EAP Method Support for Transporting AAA Payloads", Charles Clancy, 31-Jul-08, This document defines bindings for existing EAP methods to transport Diameter AVPs, called "AAA payloads". The primary application is to support EAP channel bindings, but this could be used for other applications as well. "Channel Binding Support for EAP Methods", Charles Clancy, Katrin Hoeper, 31-Jul-08, This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS problem. "Security Parameter Index multiplexed Network Address Translation (SPINAT)", Jan Melen, Jukka Ylitalo, Patrik Salmela, 27-Jul-08, This drafts defines a Security Parameter Index multiplexed Network Address Translator (SPINAT). The SPINAT method uses the SPI value of ESP packets to de-multiplex multiple IP addresses on single IP address. The solution presented in this draft requires a state in the SPINAT node and in the peer node. The state establishment requires a control signaling messages carrying the SPI values. "DNSSEC protected routing announcements for BGP", Lutz Donnerhacke, Wouter Wijngaards, 5-May-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. "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", Jonathan Hui, 28-Jul-08, This document specifies an IPv6 header compression format for IPv6 packet delivery in 6LoWPAN networks. The compression format relies on shared context to allow compression of arbitrary prefixes. This document specifies compression of well-known multicast addresses and a framework for compressing next headers. UDP compression is specified within this framework. "Proposed High-level Changes From IDNA2003 To IDNA200x", Paul Hoffman, 22-Apr-08, This document lists the changes that are proposed for IDNA200x. It covers both the changes in the initial documents from the design team and other changes proposed in the Working Group. "Sender Policy Framework: Email Address Internationalization", Frank Ellermann, 7-Sep-08, UTF8SMTP is an extension of SMTP (Simple Mail Transfer Protocol) allowing the use of UTF-8 in the SMTP envelope for EAI (Email Address Internationalization) and message headers. This memo discusses the consequences for SPF (Sender Policy Framework). "LISP EID Block", Darrel Lewis, Dave Meyer, Vince Fuller, 1-May-08, This is a direction to IANA to allocate a /8 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP) and LISP Alternative Topology (LISP+ALT) mapping system. "6LoWPAN Backbone Router", Pascal Thubert, 10-Jul-08, ISA100.11a is a Working Group at the ISA SP100 standard committee that covers Wireless Systems for Industrial Automation and Process Control. The WG is mandated to design a scalable, industrial grade LowPAN for devices such as sensors, valves, and actuators. The upcoming standard uses the 6LoWPAN format for the network header. It also introduces the concept of a Backbone Router to merge small LoWPANs via a high speed transit and scale the ISA100.11a network. This paper proposes an IPv6 version of the Backbone Router concept. "LoWPAN simple fragment Recovery", Pascal Thubert, 29-May-08, Considering that 6LoWPAN packets can be as large as 2K bytes and that an 802.15.4 frame with security will carry in the order of 80 bytes of effective payload, a packet might end up fragmented into as many as 25 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to recover individual fragments between 6LoWPAN endpoints. "Robust Header Compression over Unidirectional Lightweight Encapsulation (ULE) and MPEG2 Transport Stream (TS) frames", Tat-Chee Wan, Way-Chuang Ang, Chee-Hong Teh, 17-Jun-08, This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC4326 to carry packets compressed with RObust Header Compression (ROHC), RFC 3095 over ULE Stream. "Streamlined FTP Command Extensions", Mark Peterson, Rhino Software, 29-Aug-08, This document specifies FTP commands to download thumbnails of remote images, remove entire directory trees, request the amount of storage space available to the user, request the size of a remote directory and its contents, and to specify an FTP host. The commands are designed to reduce the number of server / client exchanges, provide information that was not previously available, and to reduce bandwidth requirements for some higher level operations. "Network Mobility Basic Support within Proxy Mobile IPv6: scenarios and analysis", Jong-Hyouk Lee, Byung-Jin Han, Tai-Myoung Chung, Hyung-Jin Lim, 20-Sep-08, As Proxy Mobile IPv6 is deployed, a Mobile Network will be initialized in or move to a Proxy Mobile IPv6 domain. In this document, the scenarios of Network Mobility Basic Support within Proxy Mobile IPv6 that ensure session continuance for all nodes in the Mobile Network are presented. In addition, an analysis of all scenarios that comprise the interactions between Network Mobility Basic Support and Proxy Mobile IPv6 is provided as a guideline to PMIPv6 deployments. "End-Point Channel Bindings for IPsec Using IKEv2 and Public Keys", Nicolas Williams, 21-Apr-08, This document specifies the end-point 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. Specifically, we use hashes of the end- points' public keys. "Double Flux Defense in the DNS Protocol", John Bambenek, 21-May-08, The memo provides information and suggests processes for developers of applications based on the DNS protocol and for administrators of servers and networks. It suggests new procedures 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. "Chrysolite - a backbone bridging solution", Mohammad Yousuf, Matthew Thomas, David Hunter, 16-Jun-08, Chrysolite is a combination of differing technologies to create a wide area switched Ethernet solution. Each Chrysolite switch has a unique MAC address (N-MAC). A link state protocol provides pairwise shortest paths between the N-MACs (one N-MAC per switch). Customers connect to the Chrysolite cloud using Ethernet connections. By setting the locally administered bit in the Ethernet address used to connect to the Chrysolite cloud, customers can directly encapsulate traffic into assigned source and destination C-MAC (MAC) addresses. Each of these C-MAC addresses specifies a unique customer 'VLAN circuit'. This proves end to end paths across the Chrysolite cloud without requiring any special headers, MAC in MAC or Q-in-Q encapsulation. "The BagIt File Package Format (V0.95) http://www.ietf.org/internet-drafts/draft-kunze-bagit-02.txt", Andy Boyko, John Kunze, Justin Littman, Liz Madden, 11-Jul-08, This document specifies BagIt, a hierarchical file package format for the exchange of generalized digital content. A "bag" has just enough structure to safely enclose a brief "tag" and a payload but does not require any knowledge of the payload's internal semantics. This BagIt format should be suitable for disk-based or network-based file package transfer. One important use case is the possibility of eventual safe return of a received bag. Tag information consists of a small number of top-level reserved file names, checksums for transfer validation, and optional small metadata blocks. "Industrial Routing Requirements in Low Power and Lossy Networks", Dust Networks, Pascal Thubert, 22-Apr-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. "Host Identity Protocol based Mobile Router (HIPMR)", Jan Melen, Jukka Ylitalo, Patrik Salmela, 27-Jul-08, This drafts defines a moving network support for HIP enabled hosts. The protocol uses asymmetric authentication and symmetric authorization. The solution presented in this draft is based on delegation of signalling rights between mobile nodes and mobile routers that results in route optimization between end-hosts. "X.509 Key and Signature Encoding for the KeyNote Trust Management System", Angelos Keromytis, 1-Oct-08, This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system [KEYNOTE]. X.509 certificates [RFC3280] can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication. In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in [RFC2792]). "A Quick Crash Detection Method for IKE", Yoav Nir, Frederic Detienne, Pratima Sethi, 12-Oct-08, This document describes an extension to the IKEv2 protocol that allows for faster detection of SA desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. "IANA Registrations for the 'Send-N' Enumservice", Ray Bellis, 23-Jun-08, This document requests IANA registration of an Enumservice 'Send-N' and extends the definition of the 'pstndata' URI scheme. This service allows more efficient support for overlapped dialling in E.164 Number Mapping (ENUM) applications. "Distributed Internet Archive Protocol (DIAP)", Damian Brasher, 6-Jul-08, A de-centralised, self-contained and managed storage protocol. A system to provide strong storage fail over by using existing resources over networks distributing vital data evenly. Rapid deployment and high redundancy for small to medium organisations as well as individuals. Designed to reduce dependency on tape backup systems. The protocol also has implications for long term archiving. By classifying data vitality values the limitations in physical space due to bandwidth constrictions can be overcome and the usefulness of DIAP maximised. "IANA Registration for an Enumservice Subtype "smpp" under Type "sms", and Information and IANA Registration for URI Type "smpp"", James Yu, 14-Apr-08, This document updates RFC 4355 by registering a new enumservice subtype "smpp" under the existing type "sms" using the URI scheme "smpp" as per the IANA registration process defined in RFC 3761 and draft-ietf-enum-enumservices-guide-07 and registers a new URI type "smpp" according to the URI registration procedure in RFC 4395. 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). "A Scalable IPv4-IPv6 Transition Architecture Need for an address-port-borrowing-protocol (APBP)", Remi Despres, 14-Jul-08, This document discusses, for the IPv4-IPv6 coexistence period, the combined requirement that: (1) legacy IPv4 hosts can establish IPv4 transport connection s from customer sites having IPv6-only permanent addresses; (2) for good scalability, no network address translations (NATs), and a fortiori no application level gateways (ALGs), need to be supported within network infrastructures. To satisfy this requirement, it is concluded that an address-port-borrowing-protocol (APBP) is needed. "Conveying Vendor-Specific Constraints in the Path Computation Element Protocol", Adrian Farrel, Greg Bernstein, 7-May-08, The Path Computation Element Protocol (PCEP) is used to convey path computation requests and responses between Path Computation Clients (PCCs) and Path Computation Elements (PCEs), and also between cooperating PCEs. In PCEP the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. The mechanisms defined for indicating objective functions include the capability to convey vendor-specific objective functions. This document defines a facility to carry vendor-specific constraints in PCEP. "Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.)", Axel Neumann, Corinna Aichele, Marek Lindner, Simon Wunderlich, 7-Apr-08, This document specifies a simple and robust algorithm for establishing multi-hop routes in mobile ad-hoc networks. It ensures highly adaptive and loop-free routing while causing only low processing and traffic cost. "Application-Layer Traffic Optimization (ALTO) Problem Statement", Enrico Marocco, Vijay Gurbani, 10-Jul-08, A significant part of the Internet traffic today is generated by peer-to-peer applications used for file sharing, realtime communications and live media streaming. Such applications often deal with large amounts of data in direct peer-to-peer connections, but they usually have little knowledge of the underlying topology, both at the overlay layer and the network layer. As a result, they may choose their peers based on measurements and statistics which, in some specific situations, often lead to suboptimal choices. This document describes problems related to optimizing traffic generated by peer-to-peer applications through the use of link and network layer information. "Website Parse Templates", Avet Manukyan, 16-Apr-08, This document defines general concepts and terminology for Website Parse Templates creation that are used to provide web crawlers/data parsers with proper information about website structure and content. "IKEv2 Mediation Extension", Tobias Brunner, 16-Apr-08, This document describes the IKEv2 Mediation Extension (IKE-ME), a connectivity extension to the Internet Key Exchange IKEv2. IKE-ME allows two peers, each behind one or more Network Address Translators (NATs) or firewalls to establish a direct and secure connection without the need to configure any of the intermediate network devices. To establish this direct connection, a process similar to Interactive Connectivity Establishment (ICE) is used. "PCEP extensions for a BGP/MPLS IP-VPN", Kenji Kumaki, Tomoki Murai, 17-Apr-08, It is highly desirable for VPN customers to be able to dynamically establish their MPLS TE LSPs in the context of a BGP/MPLS IP-VPN. In such a scenario, it is advantageous to use PCE to calculate customer MPLS TE LSPs. This document defines PCEP extensions for BGP/MPLS IP- VPNs. "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", Juergen Schoenwaelder, Alex Clemm, Anirban Karmakar, 19-Apr-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. "Unique Channel Bindings for IPsec Using IKEv2", Nicolas Williams, 21-Apr-08, This document specifies the unique channel bindings for IPsec channels constructed by connection latching, where the peers used the Internet Key Exchange protocol version 2 (IKEv2). New IKEv2 notification payloads are used to select an IKE_SA from which to derive the unique channel bindings for a given IPsec channel. "BGP ACCEPT_OWN Well-known Community Attribute", James Uttaro, Pradosh Mohapatra, David Smith, Robert Raszuk, John Scudder, 25-Apr-08, It may be useful for a BGP speaker in an autonomous system to receive and accept its own advertised route from a route reflector with more fine-grained route control. For example, the route reflector can change certain attributes of a route as desired, and then re- advertise it back to the originator. Though it is possible to perform such policy control directly at the originator, it may be operationally cumbersome in a network with a large number of border routers having complex BGP policies. This draft defines a new and well-known BGP community value, ACCEPT_OWN, that signals a BGP speaker to accept an UPDATE message and process the associated routes even when the ORIGINATOR_ID or the NEXT_HOP matches that of the receiving speaker. "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", Marc Petit-Huguenin, 8-Oct-08, This document defines two URI schemes and the resolution mechanism to convert these URIs to a list of server transport addresses that can be used between a Traversal Using Relays around NAT (TURN) client and server. "Multi-Hop Discovery of Candidate Access Routers (MHD-CAR)", Faqir Yousaf, Christian Wietfeld, 23-Apr-08, The Candidate Access Router Discovery (CARD) protocol specified in [1] is aimed to enable seamless IP layer handover by aiding seamless Layer 3 (L3) mobility management protocols like Fast Mobile IP (FMIP) by providing identity and capabilities information of the candidate access routers (CARs) to the mobile node (MN) prior to the initiation of handover while the MN is still connected to its current AR. The specifications as laid down in [1], however, specifies a very generic mechanism of the CARD protocol effective only in specific network architecture scenarios and it doesn't take into account the stringent requirements of a fast moving MN and real time communication sessions, especially when it comes to resolving candidate access routers that my be adjacent geographically but not topologically. This draft addresses the expected shortcomings of the base CARD protocol with respect to fast moving MNs and real time communication sessions by proposing extensions that is expected to improve and/or enhance the performance of the generic CARD protocol as specified in [1]. "PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", Bo Berry, Stan Ratliff, Ed Paradise, Tim Kaiser, Mike Adams, 24-Apr-08, This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. "Conversion of MIB to XSD for NETCONF", Debao Xiao, Yanan Chang, 25-Apr-08, NETCONF needs a data model for its process of standardization. This documentation defines a standard expression of SMI MIBs in XSD for NETCONF to ensure uniformity, general interoperability and reusability of existing MIBs. In addition, we define a XML schema to give a restriction and validation to translated XSD files. "Inter-technology handover in netlmm domain", Domagoj Premec, Teemu Savolainen, 26-Apr-08, Proxy Mobile IPv6 specification [Gun2008] describes a network based mobility management protocol which provides IP mobility service to a host in a way which is transparent to the host itself. This document analyses the scenario in which the MN equipped with multiple network interfaces roams in a netlmm domain consisting of several access networks. If the MN wants to preserve IP session continuity across different network interfaces as it moves from one access network to another it needs to be enhanced with a new, netlmm-specific functionality. "HTTP digest authentication using alternate password storage schemes", Luca Veltri, Stefano Salsano, Andrea Polidoro, 27-Apr-08, This document proposes to extend the HTTP Digest Authentication by adding a set new algorithms. These algorithms use different hash functions and combination of various information such as user name, realm, password, salt, and/or other data, in order to achieve compatibility with existing mechanisms used to store user credentials in various authentication/autorization servers. "A Taxonomy for New Routing and Addressing Architecture Designs", Joel Halpern, 12-Jul-08, The Routing Research Group is tasked to design a new routing architecture to meet the challenges of scalability in face of pervasive multi-homing and inter-domain traffic engineering. A number of solutions have been proposed. This draft describes a taxonomy for the design space. "LISP for Multicast Environments", Dino Farinacci, Dave Meyer, John Zwiebel, Stig Venaas, 28-Apr-08, This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. "Marking behaviour of PCN-nodes", Philip Eardley, 26-Jun-08, This document standardises the two marking behaviours of PCN-nodes: threshold marking and excess traffic marking. Threshold marking marks all PCN-packets if the PCN traffic rate is greater than a first configured rate. Excess traffic marking marks a proportion of PCN- packets, such that the amount marked equals the traffic rate in excess of a second configured rate. "Extended Random Values for TLS", Eric Rescorla, Margaret Salter, 29-Apr-08, This document describes an extension for using larger client and server Random values with Transport Layer Security (TLS) and Datagram TLS (DTLS). "ECC in OpenPGP", Andrey Jivsov, 6-Jul-08, This document proposes an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including NIST standards. The document aims to standardize an optimal but narrow set of parameters for best interoperability and it does so within the framework it defines that can be expanded in the future to allow more choices. "Capabilities Advertisement with BGP-4", John Scudder, Ravi Chandra, 29-Apr-08, This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. "Binding Revocation for IPv6 Mobility", Ahmad Muhanna, Mohamed Khalil, Sri Gundavelli, Kuntal Chowdhury, Parviz Yegani, 11-Jul-08, This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. "MAC Security Label Requirements for NFSv4", David Quigley, James Morris, 24-Jun-08, This Internet-Draft outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into NFSv4.1 . It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. It also gives a brief explanation of what kinds of protections MAC systems offer and why existing NFSv4 protection mechanisms are not sufficient. "AtomPub Multipart Media Resource Creation", Joe Gregorio, 6-Oct-08, This specification defines how an Atom Publishing Protocol collection may process multipart/related requests and also defines how a service announces that it accepts multipart/related entities. "IANA Registration for the enumservice-subtype 'sip:lr'", Otmar Lendl, 2-May-08, This document requests IANA registration of an enumservice-subtype for loose route variant for SIP, the Session Initiation Protocol. This subtype allows for the routing of SIP messages addressed to tel: Uniform Resource Identifiers (URIs) according to [I-D.rosenberg-sip-ua-loose-route]. "A Session Initiation Protocol (SIP) Event Package for Debugging", Peter Dawes, 3-May-08, This document defines a Session Initiation Protocol (SIP) event package for debugging. SIP requests and responses for session setup can traverse a number of network entities, which might be geographically spread over a large area. This document provides a means by which logging of requests and responses can be configured on a per-entity basis. "Private Extension to the Session Initiation Protocol (SIP) for Debugging", Peter Dawes, 3-May-08, Networks that use SIP to start and stop sessions between their users will frequently be upgraded with software and hardware changes. Users will similarly frequently change their client software and the way they user the network. In order to provide troubleshooting and regression testing, it is useful to provide debugging as part of the network fabric. This draft describes a SIP private header that triggers logging of SIP signalling and identifies logs at mulitiple SIP entities as belonging to a single end-to-end session. "Indication of support for keep-alive", Christer Holmberg, 10-Jun-08, This specification defines a new SIP Via header parameter, "keep" which SIP entities can use to indicate support of the NAT keep-alive techniques defined in SIP Outbound, in cases where the Outbound procedures are not supported or cannot be applied. "Overview of Existing Routing Protocols for Low Power and Lossy Networks", Arsalan Tavakoli, Stephen Dawson-Haggerty, P Levis, 8-Aug-08, Networks of low power wireless devices introduce novel IP routing issues. Low-power wireless devices, such as sensors, actuators and smart objects, have difficult constraints: very limited memory, little processing power, and long sleep periods. As most of these devices are battery-powered, energy efficiency is critically important. Wireless link qualities can vary significantly over time, requiring protocols to make agile decisions yet minimize topology change energy costs. Routing over such low power and lossy networks has requirements that existing mesh protocols only partially address. This document provides a brief survey of the strengths and weaknesses of existing protocols with respect to this class of networks. It provides guidance on how lessons from existing and prior efforts can be leveraged in future protocol design. "P2P Status and Requirements", Reinaldo Penno, 9-May-08, The use of P2P protocols by end users is widespread. These protocols are meant to exchange, replicate, stream or download files with little human intervention, trying at the same time to minimize the download time of the files requested by any single peer. The ubiquity of such P2P networks has created a steep rise in subscriber bandwidth "Deprecated HMAC MD5 in TSIG", Francis Dupont, 11-May-08, The goal of this document is to deprecate the usage of HMAC MD5 as an algorithm for the TSIG (secret key transaction authentication) resource record in the DNS (domain name system). "Definition of Managed Objects for the Neighborhood Discovery Protocol", Robert Cole, Ian Chakeres, 12-May-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 Neighborhood Discovery Protocol (NHDP) process on a router. The NHDP MIB also reports state information, performance information and notifications. This additional state and performance information is useful to management stations troubleshooting neighbor discovery problems. "WebDAV Current Principal Extension", Wilfredo Sanchez, Cyrus Daboo, 29-May-08, This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user. "Dynamic TCP Port Reuse for Large Network Address and Port Translators", Dan Wing, 14-May-08, A strawman proposal is made to reduce public-facing TCP port use with large Network Address and Port Translators (NAPTs). This proposal attempts to preserve emergent NAT traversal techniques. It is anticipated that large NAPTs will be used for NAT64. This document describes a strawman proposal for discussion on the BEHAVE mailing list, . "DKIM Author Domain Signing Practices (ADSP)", Table Contents, Author Address, Douglas Otis, 25-Jun-08, DomainKeys Identified Mail (DKIM) as described in [RFC4871], defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that lack valid DKIM signatures for domains used in the author's address. It defines a record that can advertise the extent to which a domain signs outgoing mail that is publicly exchanged on SMTP port 25, as described in [RFC2821]. Also, how other hosts can access those records. Advertisements, defined by this document, may also increase DKIM signature expectations for messages received by Mail User Agents (MUAs) or for messages which might have been exchanged over protocols other than SMTP. In some circumstances, author domains may wish to have accommodations for protocol failures or for mixed public protocol messaging not to be made. In addition, DKIM's identity parameters related to the author address are decisive only when a corresponding DKIM key local-part template precludes an author address. DKIM in conjunction with ADSP is to provide methods for detecting the spoofing of known domains, but not for making strong assertions about the identity of the message author. "Re-direct Mechanism for IKEv2", Vijay Devarapalli, Kilian Weniger, Pasi Eronen, 14-Jul-08, IKEv2 is a popular protocol for setting up VPN tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently there is no standard mechanism specified that allows an overloaded VPN gateway to re- direct the VPN client to attach to another gateway. This document proposes a re-direct mechanism for IKEv2. The proposed mechanism can also be used for Mobile IPv6 to enable the home agent to re-direct the mobile node to another home agent. "System for Managing a Shared Domain Registry", Matthew Hunt, 18-May-08, This document describes the typical usage and communication protocol of a client/server shared registry system for management of domain name registrations. The system described is a "thick registry" system, providing support for the storage and management of both the technical and the registrant contact information concerning domain registrations. The system relies on the existing HTTP and HTTPS infrastructure for transport and secure transfer to avoid having to implement a dedicated protocol and server environment. A bespoke XML format is used to communicate between clients and the SRS server. Comments are solicited and should be addressed to the mailing list at srsstandards-l@nzrs.net.nz and/or the author. The mailing list management page can be found at . "Update of legacy IANA Registrations of Enumservices", Bernie Hoeneisen, Alexander Mayrhofer, 20-May-08, This document specifies a revision of all Enumservices that have been registered at IANA under the nowadays obsolete regime of [RFC3761]. It mainly adds the new fields to the IANA Registration Template as specified in [I-D.ietf-enum-enumservices-guide], and makes at the same time some corrections of editorial nature. "Simple Mobility Solution for IPsec Clients", Srinivasa Murthy, 19-May-08, One very popular use of VPNs is to provide telecommuter access to the corporate Intranet. Remote clients that are behind NAT boxes can also access the corporate intranet with the help of the standard NAT Traversal feature. But this access may be disturbed in scenarios where a mobile user roams across different points of attachment and there by getting assigned with different IP Addresses. The access also fails in cases where the client roams across environments with NAT to environments without NAT and vice versa. In both the cases the tunnel may get re-established but it induces jitter in voice sessions. "Negotiation of Generic Image Attributes in SDP", Ingemar Johansson, Kyunghun Jung, 19-Sep-08, This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a e.g a low-end hand-held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The draft also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", Staffan Blau, Christer Holmberg, 21-May-08, This document defines an alternative connection model for MSRP UAs. The model differs from the standard MSRP model, as defined in RFC4975 and RFC4976, in that it uses SDP in a more conventional way when it comes to conveying endpoint address information, and also uses mainstream mechanisms for NAT traversal instead of using MSRP relays. "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", Alexander Mayrhofer, Christian Spanring, 21-May-08, This document specifies an Uniform Resource Identifier (URI) for geographic locations using the 'geo' scheme name. A 'geo' URI provides latitude, longitude and optionally altitude of a physical location in a compact, simple, human-readable, and protocol independent way. "IP Flow Information Accounting and Export Benchmarking Methodology", Jan Novak, 21-May-08, This document provides methodology and framework for quantifying performance implications of enabling selective monitoring of IP flows on a network device and export of this information to a collector as specified in [RFC5101]. "IP Flow Information Accounting and Export Benchmarking Methodology", Jan Novak, 21-May-08, This document provides methodology and framework for quantifying performance implications of enabling selective monitoring of IP flows on a network device and export of this information to a collector as specified in [RFC5101]. "Location Measurements for IEEE 802.16e Devices", Martin Thomson, James Winterbottom, 21-May-08, IEEE 802.16e defines means for true mobility within an 802.16 wireless network. Determining an accurate location for 802.16e devices requires information on radio parameters. A format is defined for location-related measurement data that can be provided by an 802.16e device. This measurement data can be used by a Location Information Server (LIS) to more accurately determine the location of the device. "Common YANG Data Types", Juergen Schoenwaelder, 14-Jul-08, This document introduces a collection of common data types to be used with the YANG data modeling language. "DKIM Author Domain Signing Practices (ADSP)", agent Local-part, Author Domain, Jon Callas, John Levine, Ellen Siegel, 23-May-08, DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether they sign their outgoing mail, and how other hosts can access those records. "DKIM Third-Party Authorization for Author Domain Signing Practices", Douglas Otis, 24-May-08, TPA-label is a DNS-based prefix mechanism for DKIM policy records as a means to authorize Third-Party domains. This mechanism allows first-party domains to autonomously authorize a range of third-party domains in a scalable, individual DNS transaction. This authorization extends the scope of DKIM policy assertions to supplant more difficult to administer mechanisms. Alternatives for facilitating third-party authorizations currently necessitate the coordination between two or more domains by setting up selector/key DNS records, DNS zone delegations, or the regular exchange of public/ private keys. Checking DKIM policies may occur when a From header email-address is not within the domain of a valid DKIM signature. When a Third-Party signature is found, TPA-labels offer an efficient means for email address domains to authorize specific third-party signing domains. The scope of the authorization may separately assert identity authentication for From and Sender and Resent-* headers for email- addresses within the authorizing domain. Identity authentication can be asserted by the scope of the authorization, even when signed by a Third-Party domain. In addition, the RFC2821.MailFrom domain can authorize domains for controlling DSNs. "Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP)", Chunxiu Li, Yan Li, 26-May-08, This document introduces a Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP), which is useful for the access control application of SNMP protocol. This document describes the procedure of access control in SVACM with Remote Authentication Dial In User Service (RADIUS) server for authorization. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for SVACM. "Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)", Martin Thomson, 26-May-08, The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes an BEEP feature that enables asynchrony for individual channels. "Atom Link Relation: Discuss", Peter Saint-Andre, 27-May-08, This specification defines a link relation that enables an Atom document to point to a venue for multi-party discussion of the document or its primary topic. "Securing Neighbour Discovery Proxy Problem Statement", Greg Daley, Jean-Michel Combes, 28-May-08, Neighbour Discovery Proxy is used to provide an address presence on a link from nodes which are no themselves present. It allows a node to receive packets directed at its address by allowing another device to neighbour advertise on its behalf. Neighbour Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for neighbour discovery messages. Neighbour Discovery Proxy currently cannot be secured using SEND. Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbour Discovery relates to Secured Neighbour Discovery. "Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary", Karl Wolf, 28-May-08, LoST [I-D.ietf-ecrit-lost] is able to map service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a query to the LoST server. However, the response from the LoST server does not give information about the geographical region, for which the returned service list is valid. Therefore this document proposes a ServiceListBoundary, in addition to the ServiceBoundary (which indicates the region a specific service URL is valid). "Guidelines to authors and reviewers regarding the IETF review process", Suresh Krishnan, Pasi Eronen, Eric Gray, 13-Jul-08, This document describes the authors' experiences with the IETF review process and provides guidelines to draft authors and reviewers on how to effectively participate in it. This document does not define the IETF review process itself. "Classification of Location-based Services", Andrea Forte, Henning Schulzrinne, 28-May-08, This document creates a registry for describing the types of services available at a specific location. The registry is then referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery). "In-Vehicle Routing Requirements in Low Power and Lossy Networks", Ryuji Wakikawa, Hiroshi Kuwabara, 29-May-08, This document presents the routing requirements for in-vehicle low power and lossy networks. Automobiles are already equipped with several sensors and devices named Electronic Control Unit (ECU) for controlling, monitoring and entertainment, etc. For the future in- vehicle networks, the shift to wireless is desirable due to heavy weight and volume of cables in vehicles and to be able to efficiently install devices. However, with the limitation of low power, in- vehicle network still requires reliability and scalability in nature of the rolls of ECU. The routing protocol should support the features of low-power, high-reliability, Subnetting, QoS, Mobility, etc. This document briefly explains the in-vehicle networks and ECUs, then discusses the requirements for the future wireless in- vehicle networks. "DHCPv6 Prefix Delegation for NEMO", Ralph Droms, Pascal Thubert, Francis Dupont, Wassim Haddad, 30-May-08, One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. "Random Data Encryption Mechanism (RDEM)", Mukul Jaitly, 1-Jun-08, This document describe an data encryption specification which is based on random bytes selection of data and random key generation. This encryption process accepts variable input and the key size is dependent on the input data. This encryption process does not depend upon any 128 or 256 fixed block encryption. The mechanism for encryption is simpler to implement, but gives key complexity of more than 256 bit encryption. "Real-Time Transport Protocol (RTP) Timestamps for Layered Encodings", Jonathan Lennox, Thomas Schierl, Sam Ganesan, 2-Jun-08, The Real-Time Transport Protocol (RTP) specification defines how layered encodings can be sent over a layered transmission system. A source can stripe the progressive layers of a hierarchically represented signal across multiple RTP sessions, each carried on, for example, its own multicast group. These layered encodings are given special treatment in RTP, notably in that the same synchronization source (SSRC) identifier space is used across the sessions of all layers. The RTP protocol specification does not, however, explicitly state how RTP timestamps are to be used with layered encodings. This document updates the RTP specification to require that RTP timestamps for layered encodings be synchronized, i.e. that every layer chooses the same random initial value for the timestamp. "Proxy Mobile IPv6 Inter-Technology Handover Issue", Behcet Sarikaya, Frank Xia, 3-Jun-08, Proxy Mobile IPv6 (PMIPv6) is a mobile node agnostic mobility management protocol, that is, a mobile node does not take part in any mobility signaling. In inter-technology handovers, mobile node input is required in moving IP sessions from one interface to the other. This document discusses the impact of the mobile node involvement during inter-technology handover. "Dynamic Home Agent Address Discovery (DHAAD) Considered Harmful", Francis Dupont, Jean-Michel Combes, Maryline Laurent-Maknavicius, 3-Jun-08, The Dynamic Home Agent Address Discovery (DHAAD) mechanism is described in the Mobile IPv6 specification. This mechanism is mandatory in any compliant Mobile IPv6 implementation and so in any MIPv6 based protocols too. On the other hand, DHAAD was the only one mechanism to discover a potential Home Agent for a Mobile Node in the past. This is no longer the case today. This document analyzes the security of the different existing home agent discovery mechanisms and promotes the remove of DHAAD from the future Mobile IPv6 standard, in light of this security analysis. "SeND Hash Threat Analysis", Ana Kukec, Suresh Krishnan, Sheng Jiang, 1-Jul-08, This document analysis the use of hashes in SeND, possible threats and the impact of recent attacks on hash functions used by SeND. Current SeND specification [rfc3971] uses SHA-1 [sha-1] hash algorithm and PKIX certificates [rfc3280] and does not provide support for the hash algorithm agility. Based on previous analysis, this document suggests multiple hash support that should be included in the SeND update specification. "Session Multiplexing for SVC Video", Miska Hannuksela, Ye-Kui Wang, 14-Jul-08, This memo describes two alternative methods for decoding order recovery of the Network Abstraction Layer (NAL) units carried in multiple RTP sessions for Scalable Video Coding (SVC), which is defined in Annex G of the ITU-T Recommendation H.264 video codec that is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The methods apply when non-interleaved transmission of NAL units using the Single NAL Unit packetization mode or the Non-Interleaved packetization mode defined in RFC 3984 is in use. Table of Contents Status of this Memo...............................................1 Copyright Notice..................................................1 Abstract..........................................................2 "Reserved Top Level DNS Names", Frank Ellermann, Donald Eastlake 3rd, 18-Aug-08, To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This memo replaces RFC 2606 reserving 21 additional TLDs. "DHCP Reconfigure Extension Option", Vitali Vinokour, Wojciech Dec, James Bristow, David Miles, 6-Jun-08, The current use of DHCP (Dynamic Host Configuration Protocol) Reconfigure extension is limited by a requirement that FORCERENEW message is authenticated. This document defines a mechanism allowing the use of FORCERENEW without DHCP authentication. "Secure Proxy ND Support for SEND", Suresh Krishnan, Julien Laganier, Marco Bonola, 6-Jun-08, Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As specified today, SEND assumes that the node advertising an address is the owner of the address and is in possession of the private key used to generate the digital signature on the message. This means that the Proxy ND signaling initiated by nodes that do not possess knowledge of the address owner's private key cannot be secured using SEND. This document extends the current SEND specification with support for Proxy ND, the Secure Proxy ND Support for SEND. "BGP Extended Community Attribute for QoS Marking", Thomas Martin Knoll, 14-Jul-08, This document specifies a simple signalling mechanism for inter- domain QoS marking using several instances of a new BGP Extended Community Attribute. Class based packet marking and forwarding is currently performed independently within ASes. The new QoS marking attribute makes the targeted Per Hop Behaviour within the IP prefix advertising AS and the currently applied marking at the peering point known to all access and transit ASes. This enables individual (re-)marking and possibly forwarding treatment adaptation to the original QoS class setup of the respective originating AS. The attribute provides the means to signal QoS markings on different layers, which are linked together in QoS Class Sets. It provides inter-domain and cross-layer insight into the QoS class mapping of the source AS with minimal signalling traffic. "BGP ACCEPT_OWN Well-known Community Attribute", James Uttaro, Pradosh Mohapatra, David Smith, Robert Raszuk, John Scudder, Intellectual Property, 8-Jun-08, Under certain conditions it is desirable for a BGP route reflector to be able to modify the Route Target list of a VPN route that is distributed by the route reflector, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same PE as the VRF(s) that import the route. However, due to the constraints of the BGP protocol, it does not work if the two are on the same PE. This document describes a modification to the BGP protocol allowing this technique to work when the VRFs are on the same PE, allowing the technique to be used in a standard manner throughout an autonomous system. "Clarifying Handling of M & O Flags of IPv6 Router Advertisement", Hyunwook Cha, Bernie Volz, 8-Jun-08, This document clarifies how clients are supposed to use the RA M & O flags. "ISP Shared Address after IPv4 Address Exhaustion", Shin Miyakawa, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 9-Jun-08, This document defines IPv4 "ISP Shared Address" to be jointly used among Internet Service Providers. This space is intended to enable Internet Service Providers' continuous IPv4 based operation even after the IPv4 address exhaustion. "NAT64/DNS64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van Beijnum, 19-Sep-08, NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A records. These two mechanisms together enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated by either end using existing, NAT-traversing, peer-to-peer communication techniques. This document specifies NAT64 and DNS64, and gives suggestions on how they should be deployed. "Display-based Address Sorting for the IMAP4 SORT Extension", Dan Karp, 10-Jun-08, This document describes an IMAP protocol extension enabling server- side message sorting based on the commonly-displayed portion of the From header. "IMAP4 Extension for returning STATUS information in extended LIST", Alexey Melnikov, Timo Sirainen, 10-Jun-08, Many IMAP clients display information about total number of messages/ total number of unseen messages in IMAP mailboxes. In order to do that they are forced to issue a LIST or LSUB command, to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command.Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. "A New BGP Standards Action Community, LAST_RESORT", Brian Dickson, 20-Aug-08, This Internet Draft describes a new Standards Action BGP community, LAST_RESORT. This community provides a simple and easily deployable solution to a certain class of BGP "wedgies". Initial deployment is expected to be achieved by voluntary use in the network operator community-at-large. Long-term adoption via software enforcement of the community, will improve global behavior, and simplify router configurations. The Standards Action range of communities (previously limited to the "well-known" communities) ensures that the expectation of (eventual) router support is reasonable. "Additional DNS Resource Records", Randall Atkinson, 11-Jun-08, This note describes four additional optional Resource Records for use with the Domain Name System (DNS). At present these optional resource records are subject of experimentation in certain IP networks. Limited deployment is anticipated in the near future. "IPv6 RADIUS attributes for DHCP based networks", Benoit Lourdelet, 12-Jun-08, This document specifies RADIUS [RFC2865] attributes supporting IPv6 network access to complement [RFC3162] in DHCP environments. It addresses the need to dynamically advertise DNS Server addresses and one or multiple IPv6 addresses via DHCPv6. "Nonce Destination Option", Randall Atkinson, 12-Jun-08, This document describes an experimental Nonce Destination Option that could be used as part of an Identifier Locator Network Protocol (ILNP) that is based upon IPv6. "GRE key as the traffic selector for IPsec tunnel", Hui Deng, Yuanchen Ma, Yingzhe Wu, 13-Jun-08, This document describes the IPsec Tunnel based on GRE key as the traffic selector. When GRE key is used in IP packet transmission scenario of the wireless communication. Several enterprise need different security policy when transmit the packet through some unguaranteeded Internet cloudy. This document propose to adopt GRE key as the IPsec traffic selector. "The application/opensearchdescription+xml media type", Frank Ellermann, 3-Jul-08, This memo defines the application/opensearchdescription+xml media type for OpenSearch descriptions. Atom and XHTML elements are examples where this media type is used. "Providing Satellite Navigation Assistance Data using HELD", Martin Thomson, James Winterbottom, 15-Jun-08, This document describes a method for providing Global Navigation Satellite System (GNSS) assistance data using the HTTP-Enabled Location Delivery (HELD) protocol. An assistance data request is included with the HELD location request and the Location Information Server (LIS) provides assistance data along with location information. "Neighbor Discovery Registration Extension", Erik Nordmark, 16-Jun-08, In order to reduce Neighbor Discovery multicast messages it is useful if the routers on a link can maintain an authoritative list of the IPv6 and layer 2 addresses for all the hosts on the link. This draft specifies an extension to the Router Advertisement messages which trigger to hosts to send periodic registration messages which can be either unicast, multicast, or anycast. The protocol uses a soft-state approach to gather registration information. "Attention Request (POKE) for Instant Messaging", Gustavo Garcia, Jose-Luis Martin, 16-Jun-08, This document specifies a message content type and XML format to request attention from a targeted user. This feature is usually known as poke, nudge or buzz in existing messaging platforms. Its primary use is as an additional instant messaging capability that can be sent in the middle of a instant messaging session or in a standalone message at any time. This message also allows the sender to indicate the preferred realization of the attention request: vibrator, light, tone, media or text. "Requirements for correlation of multiple SIP sessions for user to user communications.", Gonzalo Camarillo, Salvatore Loreto, 16-Jun-08, This document shows the need and list the requirements to logically correlate an existing SIP dialog, or even multi SIP transactions sent outside of a dialog, with a new SIP dialog. This mechanism can be used to implement applications using multiple SIP sessions but also in peer-to-peer call control environments. "Conversion parameters for IMAP CONVERT", Alexey Melnikov, 20-Jun-08, This is a companion document to the Lemonade CONVERT (draft-ietf-lemonade-convert-XX.txt) extension. It defines additional conversion parameters for conversions of image/* and text/* body parts. It also demonstrates additional CONVERT usage scenarios. "Pairtrees for Object Storage (V0.1)", John Kunze, Martin Haye, Erik Hetzner, Mark Reyes, 17-Jun-08, This document specifies Pairtree, a filesystem hierarchy for holding objects that are located by mapping identifier strings to object directory (or folder) paths two characters at a time. If an object directory (folder) holds all the files, and nothing but the files, that comprise the object, a "pairtree" can be imported by a system that knows nothing about the nature or structure of the objects but can still deliver any object's files by requested identifier. The mapping is reversible, so the importing system can also walk the pairtree and reliably enumerate all the contained object identifiers. To the extent that object dependencies are stored inside the pairtree (e.g., fast indexes stored outside contain only derivative data), simple or complex collections built on top of pairtrees can recover from index failures and reconstruct a collection view simply by walking the trees. Pairtrees have the advantage that many object operations, including backup and restore, can be performed with native operating system tools. "BGP Communities use for the prefix origination tagging", Dave Meyer, Matvey Teplov, 17-Jun-08, BGP communities [RFC 1997] are 64-bit values that are used to tag the originated or traversing prefixes for the different purposes, such as origination tagging or policy application purposes. These values can be displayed in a new and old format, which notes different representation of the same 64-bit value. This document defines the way of tagging prefixes based upon their geographical origination to assist in development of geographically-based policies that, ideally, will result in RTD (Round Trip Delay) value improvements, as optimized paths can be established. "Sender RTT Estimate Option for DCCP", Gerrit Renker, 18-Jun-08, This document describes an optional extension for DCCP congestion- control CCIDs that are based on TCP-Friendly Rate Control (TFRC). The extension improves the accuracy of parameter estimation at the TFRC receiver, by periodically communicating the (more precise) RTT estimate available at the sender. "Transient Binding for Proxy Mobile IPv6", Marco Liebsch, Ahmad Muhanna, Oliver Blume, 14-Jul-08, This document specifies a mechanism which enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry which is used for inter-MAG handover optimization. This mechanism is applicable to the mobile node's inter-MAG handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at a mobility anchor is described. The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. "HIP support for RFID", Pascal Urien, 18-Jun-08, This document describes an architecture based on the Host Identity Protocol (HIP), for active tags, i.e. RFIDs that include tamper resistant computing resources, as specified for example in the ISO 14443 or 15693 standards. HIP-Tags never expose their identity in clear text, but hide this value (typically an EPC-Code) by a particular equation (f) that can be only solved by a dedicated entity, referred as the portal. HIP exchanges occurred between HIP- Tags and portals; they are shuttled by IP packets, through the Internet cloud. "TLS Key Generation", Pascal Urien, 18-Jun-08, The TLS protocol is widely deployed and used over the Internet. Client and server nodes compute a set of keys called the key-block, according to a pseudo random function (PRF). This draft proposes a keying infrastructure based on the TLS protocol. It suggests defining an additional Key Distribution Function (KDF) in order to deliver a set of cryptographic keys. In a peer to peer mode keys are directly produced as inputs of the KDF functions. For centralized architectures they are delivered through containers, secured with keys derived from the KDF function. "Things To Be Considered for RFC 3484 Revision", Arifumi Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, Ken-ichi Kanayama, 19-Jun-08, RFC 3484 has several known issues to be fixed mainly because of the deprecation of IPv6 site-local unicast address and the coming of ULA. Additionally, the rule 9 of the destination address selection rules, namely the longest matching rule, is known for its adverse effect on the round robin DNS technique. This document covers these essential points to be modified and proposes possible useful changes to be included in the revision of RFC 3484. "Mobile IPv6 Flow Routing over Multiple Care-of Addresses", Michael Eriksson, Conny Larsson, Romain Kuntz, 19-Jun-08, This document specifies a mechanism to selectively route IP flows to and from Mobile IPv6 Mobile Nodes and NEMO Mobile Routers which have registered multiple care-of addresses. It explains how to apply the generic flow distribution language defined in a companion draft to Mobile IPv6, defines a transport mechanism to transmit the rules between Mobile IPv6 nodes, and describes how the rules are sent and handled upon reception. "IANA Registration for Location ('loc') Enumservice", Alexander Mayrhofer, 19-Jun-08, This document requests IANA registration of an Enumservice for reflecting location information. The Enumservice uses the 'loc' Type name, and makes use of the proposed 'held' and 'geo' URI schemes. "Channel binding for HTTP Digest Authentication", Stefan Santesson, 14-Jul-08, This document specifies a method implemented by Microsoft to add channel binding capabilities to the http digest protocol defined in RFC 2617 [2617] "Multicast tunneling optimization for Mobile IPv4", Hui Deng, 20-Jun-08, This document provides the solution to optimize the multicast tunneling in mobile IPv4. This solution will not break the basic bi- directional tunneling multicast solution of MIPv4. A new multicast foreign agent works as a proxy node for multiple mobile nodes within one limit scope. Single tunnel is set up between one home agent and one mobile foreign agent for single multicast stream. A new notification message is created for the communication between home agent and multicast foreign agent. There is no modification on mobile nodes. "Stream Control Transmission Protocol (SCTP) Stream Reset", Randall Stewart, Peter Lei, Michael Tuexen, 20-Jun-08, Many applications that desire to use SCTP have requested the ability to "reset" a stream. The intention of resetting a stream is to start the numbering sequence of the stream back at 'zero' with a corresponding notification to the upper layer that this act as been performed. The applications that have requested this feature normally desire it so that they can "re-use" streams for different purposes but still utilize the stream sequence number for the application to track the message flows. Thus, without this feature, a new use on an old stream would result in message numbers larger than expected without a protocol mechanism to "start the streams back at zero". This documents presents also a method for resetting the transport sequence numbers and all stream sequence numbers. "Safe IKE Recovery", Frederic Detienne, Pratima Sethi, Yoav Nir, 6-Aug-08, The Internet Key Exchange protocol version 2 (IKEv2) suffers from the limitation of not having a means to quickly recover from a stale state known as dangling Security Associations (SA's) where one side has SA's that the corresponding party does not have anymore. This Draft proposes to address the limitation by offering an immediate, DoS-free recovery mechanism for IKE that can be used in all failover or post-crash situations. "Signaling Cryptographic Algorithm Understanding in DNSSEC", Steve Crocker, Scott Rose, 14-Jul-08, The DNS Security Extensions (DNSSEC) was developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. Each digital signature added to a response increases the size of the response, which could result in the response message being truncated. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms they prefer in a DNSSEC response by defining an EDNS option to list a client's preferred algorithms. "MPLS Generic Associated Channel", Matthew Bocci, David Ward, 20-Jun-08, This draft describes a generic associated channel header (GE-ACH) that provides a control channel associated with an MPLS LSP, pseudowire or MPLS section. The VCCV ACH defined for PWs in RFC 5085 is generalized to allow a larger set of control channel and OAM functions to be used to meet the requirements of packet transport and other applications of MPLS. "JWT Report on MPLS Architectural Considerations for a Transport Profile", Stewart Bryant, Loa Andersson, 20-Jun-08, This RFC archives the report of the IETF - ITU-T Jooint Working Team (JWT) on the application of MPLS to Transport Networks. The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM, survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process. There are two versions of this RFC. An ASCII version that contains a summary of the slides and a pdf version that contains the summary and a copy of the slides. "Distributing a Symmetric Neighbor Discovery Key Using SEND", Frank Xia, Suresh Krishnan, Wassim Haddad, Jean-Michel Combes, Chunqiang Li, 20-Jun-08, In this document, a method for provisioning a shared key from the router to the host is defined to protect Neighbor Discovery(ND) signaling between the router and the host. The host sends a Router Solicitation(RS) message with ND Shared Key Request Option to the router. The router encrypts a ND shared key using the host's SEcure Neighbor Discovery(SEND) public key and sends it back to the host through a Router Advertisement(RA) message. The host decrypts the ND shared key using the matching private key. The Neighbor Discovery shared key is then used for protecting the following Neighbor Discovery signaling between the router and the host. The Router Solicitation and Router Advertisement message exchanges are required to have SEND security. "Dissemination of flow specification rules implementation report", Robert Raszuk, Pedro Roque Marques, Craig Labovitz, 21-Jun-08, This document provides an implementation report for Dissemination of flow specification rules as defined in draft-ietf-idr-flow-spec-01 The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. "Alternative RPKI Repository Retrieval Mechanism", Terry Manderson, George Michaelson, 23-Jun-08, This document proposes a mechanism for a relying party to synchronise a local cache of the RPKI repository using a HTTP retrieval mechanism. "A three state extended PCN encoding scheme", T Moncaster, Bob Briscoe, Michael Menth, 23-Jun-08, Pre-congestion notification (PCN) is a mechanism designed to protect the Quality of Service of inelastic flows. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This baseline encoding specified how two encoding states could be encoded into the IP header. This document specified an extension to the baseline encoding that enables three encoding states to be carried in the IP header as well as enabling limited support for end-to-end ECN. Status This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC. "No Service To This Number Reject Code", David Schwartz, 23-Jun-08, The Session Initiation Protocol (SIP) allows for users to make calls using telephone numbers embedded in either "sip" [RFC3261] or "tel" [RFC3966] URIs. Either way, the telephone number (TN) itself is not restricted and can represent an entity in the public telephone network, an entity in a private telephone network or an entity on the Internet. This TN resolution ambiguity highlights the difference between the LUF and LRF functions defined in [I-D.draft-ietf-speermint-terminology] and underscores the need for more precise SIP error rejection codes. SIP has no way to indicate to the calling UAC that the reason for call rejection is due to the fact that this number does not exist in the requested domain or realm but it does exist in the public telephone network for instance. Such an indication is useful to allow the call to be retried at a different context (i.e. the public PSTN in this case) with possibly better results. This specification defines a new SIP response code for this purpose. "Optimized MAC Address Operations in VPLS with Redundancy", Yuanlong Jiang, Yang Yang, 24-Jun-08, The Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling is described in RFC 4762. That document describes a mechanism called MAC Address Withdrawal to remove or unlearn MAC addresses which have been dynamically learned in a VPLS instance. Further work in progress defines an extension to MAC Address Withdrawal procedure which can greatly restrict the scope of MAC flushing. This document provides two mechanisms which completely remove the need for MAC address flushing in VPLS instances. The mechanisms are MAC address switching and MAC address notification. "Progress and future development of Flow State Aware standards, and a proposal for alerting nodes or end-systems on data related to a flow", jongtae song, John Adams, Jinoo Joung, 24-Jun-08, This document describes the work in progress on Flow State Aware standards activity in the ITU and proposes a new type of control packet to be identified that can alert downstream or upstream nodes on data related to an individual flow. "PW Bonding", Yaakov Stein, Itai Mendelsohn, Ron Insler, 25-Jun-08, There are times when pseudowires must be transported over physical links with limited bandwidth. We shall use the term "bonding" (also variously known as inverse multiplexing, link aggregation, trunking, teaming, etc.) to mean an efficient mechanism for separating the PW traffic over several links. Unlike load balancing and equal cost multipath, bonding makes no assumption that the PW traffic can be decomposed into distinguishable flows, and thus bonding requires delay compensation and packet reordering. Furthermore, PW bonding can optionally track bandwidth constraints in order to minimize packet loss. "Trusted plane for routing equipment embedding a tamper-resistant device", Evren Bulut, Emmanuel Onfroy, 25-Jun-08, Due to their critical role in a network, the protection of routing equipements is crucial, particularly against subversion attacks. For this purpose, we integrate a trusted plane in the network equipments related to the routing protocols (e.g. OSPF, BGP, RIP). This trusted plane is realized by a trusted element embedded or connected to the network equipment. "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", Staffan Blau, Christer Holmberg, 12-Sep-08, This document defines an alternative connection model for MSRP UAs. The model differs from the standard MSRP model, as defined in RFC4975 and RFC4976 in the following ways: it uses SDP in a more conventional way when it comes to conveying endpoint address information, and it uses COMEDIA for connection establishment. Because of this, the model also allows for the usage of mainstream mechanisms for NAT traversal, instead of using MSRP relays. "RTP Payload Format for Geographical Location.", Xavier Marjou, Jean Jestin, 26-Jun-08, This memo presents some use-cases and requirements related to the real-time transport of geographical location information. It also defines a Real-time Transport Protocol (RTP) packet payload format to carry real-time geographical location information. "Assignment of the Generic Associated Channel Header Label (GAL)", Martin Vigoureux, George Swallow, Rahul Aggarwal, David Ward, Matthew Bocci, 26-Jun-08, This document describes the assignment of one of the reserved label values, defined in RFC 3032 [3], to the 'Generic-ACH Label (GAL)', that is used as generic exception mechanism, for example by MPLS Transport Profile (MPLS-TP) for Operations and Management (OAM) functions. "On RFC Streams, Headers, and Boilerplates", Leslie Daigle, Olaf Kolkman, 6-Oct-08, RFC documents contain a number of fixed elements such as the title page header, standard boilerplates and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. "IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", Remi Despres, 27-Jun-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 allows 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). "A Diffserv-TE Implementation Model to dynamically change booking factors during failure events", Jonathan Newton, Mustapha Aissaoui, JP Vasseur, 27-Jun-08, This document discusses the requirements for and describes an implementation model of Diffserv-TE that allows the booking factors applied to network resources to be dynamically changed during network failure events. "MPLS Generic Associated Channel", Matthew Bocci, David Ward, Stewart Bryant, Italo Busi, Martin Vigoureux, 27-Jun-08, This draft describes a generic associated channel header (GE-ACH) that provides a control channel associated with an MPLS LSP, pseudowire or MPLS section. The VCCV ACH defined for PWs in RFC 5085 is generalized to allow a larger set of control channel and OAM functions to be used to meet the requirements of packet transport and other applications of MPLS. "Indicating Non-Availability of Dynamic Updates in the DNS", Joe Abley, 27-Jun-08, The Start of Authority (SOA) Resource Record (RR) in the Domain Name System (DNS) specifies various parameters related to the handling of data in DNS zones. These parameters are variously used by authority- only servers, caching resolvers and DNS clients to guide them in the way that data contained within particular zones should be used. One particular field in the SOA RR is known as MNAME, which is used to specify the "Primary Master" server for a zone. This is the server to which Dynamic Updates are sent by clients. Many zones do not accept updates using the Dynamic Update mechanism, and any such DNS UPDATE messages which are received provide no usual purpose. For such zones it may be preferable not to receive updates from clients at all. This document proposes a convention by which a zone operator can signal to clients that a particular zone does not accept Dynamic Updates. "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Luca Martini, Samer Salam, Ali Sajassi, Satoru Matsushima, Thomas Nadeau, 27-Jun-08, This document specifies an inter-chassis communication protocol (ICCP) that enables PE redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a redundancy group, for the purpose of synchronizing data amongst the systems. It accommodates multi-chassis attachment circuit as well as pseudowire redundancy mechanisms. "Clarification of sender behaviour in persist condition.", Murali Bashyam, Mahesh Jethanandani, Anantha Ramaiah, 28-Jun-08, This document attempts to clarify the notion of the Zero Window Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The motivation for this document stems from the belief that TCP implementations strictly adhering to the current RFC language have the potential to become vulnerable to Denial of Service (DoS) scenarios. "Mobility Support in IPv4/v", Zhengming Ma, Qingyu Tan, Zheng Xiang, 30-Jun-08, This document specifies a protocol named Mobile IPv4/v6, which allows mobile nodes to remain reachable while moving in IPv4/v6 mixed networks. A translation gateway called Mobile IPv4/v6 Translation Gateway (MIPv4/v6-TG) is introduced in this protocol. MIPv4/v6-TG is based on NAT-PT gateway and equipped with a newly introduced application level gateway called MIP-ALG. MIPv4/v6-TG is located between IPv4 network and IPv6 network. On IPv4 network side, MIPv4/v6-TG acts as a Mobile IPv4 entity and interacts with other Mobile IPv4 entities under Mobile IPv4, while on IPv6 network side, it acts as a Mobile IPv6 entity and interacts with other Mobile IPv6 entities under Mobile IPv6. In MIPv4/v6-TG, Mobile IPv4 entities and Mobile IPv6 entities are translated with each other. In order to maintain each of Mobile IP sessions that pass through MIPv4/v6-TG, a data structure called Mobile IP Table is introduced. "AtomTriples: Embedding RDF Statements in Atom", Mark Nottingham, Dave Beckett, 30-Jun-08, This specification describes AtomTriples, a set of Atom extension elements for embedding RDF statements in Atom documents (both element and feed), and declaring how they can be derived from existing content. "Performance Evaluation of PCE Architectures for Wavelength Switched Optical Networks", Greg Bernstein, 30-Jun-08, In this note a number of PCE architectural and computational options are evaluated against a medium sized wavelength switched optical network. The key performance measures of overall and backward blocking are reported under different dynamic traffic scenarios. The corresponding reduction in connection blocking probabilities and computational advantages enabled by these architectural alternatives strongly warrant their inclusion in continuing PCE WSON work. "IPv6 CPE Router Recommendations", Hemant Singh, Wes Beebee, 14-Jul-08, This document recommends IPv6 behavior for Customer Premises Equipment (CPE) routers in Internet-enabled homes and small offices. The CPE Router may be a standalone device. The CPE Router may also be embedded in a device such as a cable modem, DSL modem, cellular phone, etc. This document describes the router portion of such a device. "Requirements for Label Edge Router Forwarding of IPv4 Option Packets", William Jaeger, John Mullooly, Tom Scholl, David Smith, Intellectual Property, 6-Oct-08, This document imposes a new requirement on Label Edge Routers (LER) specifying that when determining whether to MPLS encapsulate an IP packet, the determination is made independent of any IP options that may be carried in the IP packet header. Lack of a formal standard may result in a different forwarding behavior for different IP packets associated with the same prefix-based Forwarding Equivalence Class (FEC). While an IP packet with either a specific option type or no header option may follow the MPLS label switched path (LSP) associated with a prefix-based FEC, an IP packet with a different option type but associated with the same prefix-based FEC may bypass MPLS encapsulation and instead be IP routed downstream. IP option packets that fail to be MPLS encapsulated simply due to their header options present a security risk against the MPLS infrastructure. "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", Kevin Igoe, Jerome Solinas, 30-Jun-08, Secure Shell (SSH) [RFC4251] is a secure remote-login protocol. SSH provides for algorithms that provide authentication , key agreement. confidentiality and data integrity services. This purpose of this document is to show how the AES Galois/Counter Mode can be used to provide both confidentiality and data integrity. "Certified Pan Formation Protocol", Aroua Biri, 30-Jun-08, This draft introduces the Certified PN Formation Protocol (CPFP) based on the personal public key infrastructure (personal PKI) concept. CPFP employs Elliptic Curve Cryptography (ECC) techniques by using ECDH, ECDSA and STS protocols and provides feasible solutions for key revocation and transitive imprinting. "Certified Electronic Mail", Francesco Gennai, Alba Shahin, Claudio Petrucci, Alessandro Vinciarelli, 30-Jun-08, Since 1997, the Italian Laws have recognized electronic delivery systems as legally usable. After 2 years of technical tests, in 2005 the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal value. Design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (CNIPA), followed by efforts for the implementation and testing of the service. The CNIPA has given the Italian National Research Council (CNR), and in particular The Institute of Information Science and Technologies at the CNR (ISTI), the task to run tests on providers of the service to guarantee the correct implementation and interoperability.This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. "1 + /64s as IPv6 Standard Access Model", Shin Miyakawa, Yasuhiro Shirasaki, 30-Jun-08, This document proposes the "standard" address assignment scheme for IPv6 access network which uses RA or DHCPv6 to assign an global IPv6 address to the WAN interface of the CPE and DHCPv6 PD on the upstream link of CPE to delegate one or more /64 prefixes to the CPE. "Load Balancing for Mesh Softwires", Clarence Filsfils, Pradosh Mohapatra, Carlos Pignataro, 1-Jul-08, Payloads carried over a Softwire mesh service as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange often carry a number of identifiable, distinct flows. It can in some circumstances be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers. Thus the load balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation. "DHCPv4 bulk lease query", D.T.V. Ramakrishna Rao, Bharat Joshi, Pavan Kurapati, 1-Jul-08, The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a client to request information about DHCPv4 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv4 binding data via TCP. "Generic Mobility Management Protocol", Hui Deng, 1-Jul-08, This document discusses the communication protocol between mobile access point and terminal. With the evolution of mobile communication, there are various kind of wireless communication technologies such as WCDMA, LTE, WLAN, WiMAX, and TDS-CDMA et al. Each of these wireless communication technology has independent connection, mobility and configuration management. This document would like to cover all these functions into a common ground especially in the environment of multiple connections. "Extension headers for 6lowpan", Carsten Bormann, 1-Jul-08, 6lowpan applications sometimes need to include application-specific information in layer 2 packets that are intended to be processed as 6lowpan packets. This document specifies a way to include this information in a 6lowpan packet in such a way that it can be ignored by implementations that don't care for it. $Id: draft-bormann-6lowpan-ext-hdr.xml,v 1.5 2008/07/02 06:23:58 cabo Exp $ "Carrier Grade Network Address Translator (NAT) Behavioral Requirements for Unicast UDP, TCP and ICMP", Tomohiro Nishitani, Shin Miyakawa, 2-Jul-08, This document defines basic terminology for describing different types of carrier-grade Network Address Translation (NAT) behavior when handling Unicast UDP, TCP and ICMP. Developing carrier-grade NATs that meet this set of requirements increase transparency of data between carrier networks. "Application of Event Package Bodies to Subscriptions to Lists of Resources in the Session Initiation Protocol (SIP)", Adam Roach, 2-Jul-08, This document specifies a mechanism by which subscriptions to the state of request-contained ("ad-hoc") lists of resources can have event-package-defined bodies applied to each of the contained resources. "DHCP Based Configuration of Mobile Node from Home Network", Hui Deng, 2-Jul-08, This document describes the mechanism for providing the host configuration parameters needed for network service from home network based on DHCPINFORM. DHCPINFORM message has been widely used by client to obtain other configuration information and could be sent to local broadcast address or server unicast address. Mobile IP specification could support DHCPINFORM broadcast or unicast message straightfully without any revision. "DKIM Extensions", Phillip Hallam-Baker, 13-Jul-08, Optional extensions for DKIM are described. A DKIM Policy statement is defined for the policy 'this zone never sends mail'. The NULL Key Algorithm is defined to simplify management of large zones where most mail is signed but with important exceptions. The X509 key record extension allows the location from which an X.509v3 certificate for the key specified in the record may be obtained. "Diameter User-Name and Realm Based Request Routing Clarifications", Jouni Korhonen, Mark Jones, Lionel Morand, Tina Tsou, 2-Jul-08, This specification clarifies the Diameter realm based request routing. We focus on the case where a Network Access Identifier in the User-Name AVP is used to populate the Destination-Realm AVP and the Network Access Identifier contains more than one realm. This particular case is possible when the Network Access Identifier decoration is used to force a routing of request messages through a predefined list of realms. However, this functionality is not unambiguously specified in the Diameter Base Protocol specification. "Moving the Session Initiation Protocol (SIP) Towards Draft Standard", Robert Sparks, 2-Jul-08, This document is intended to stimulate discussion and progress towards advancing SIP to Draft Standard. It points to some of the issues the working group will need to work through and proposes an approach for creating an interoperability statement. "RFC 2026 in practice", Brian Carpenter, 2-Jul-08, This document discusses how RFC 2026, the current description of the IETF standards process, operates in practice. Its main purpose is to document, for information only, how actual practice interprets the formal rules. "Specifying Unsafe Areas in LoST Service Boundary", Qian Sun, Robins George, 2-Jul-08, This document describes how to specify unsafe areas in LoST for emergency services, such as police, mountain, marine and fire. "Location-to-Service Translation Protocol (LoST) Sub-Services", Robins George, Qian Sun, 2-Jul-08, This document describes, how a LoST client can ask LoST server for the list of sub services that it supports, and to incorporate additional information about the service provider in response. "Providing Satellite Navigation Assistance Data using HELD", Martin Thomson, James Winterbottom, 2-Jul-08, This document describes a method for providing Global Navigation Satellite System (GNSS) assistance data using the HTTP-Enabled Location Delivery (HELD) protocol. An assistance data request is included with the HELD location request and the Location Information Server (LIS) provides assistance data along with location information. "A Packet Partition Scheduling Mechanism for Bandwidth Aggregation through Multiple Network Interfaces", Pyung-Soo Kim, Joo-Young Yoon, Han-Lim Kim, 2-Jul-08, This draft considers a packet partition scheduling mechanism for effective bandwidth aggregation over end-to-end multi-path through multiple network interfaces. "IPv6 in Broadband Networks", John Kaippallimalil, Frank Xia, 3-Jul-08, This document describes IPv6 link models and their applicability in a fixed broadband network architecture. This document also specifies the addressing and operation of IPv6 in broadband networks. The scope of this specification is limited to the operation of IPv6 in a broadband architecture. This includes the IPv6 link model, address configuration, router and neighbor discovery in broadband architecture. "Pointers for Peer-to-Peer Overlay Networks, Nodes, or Resources", Ted Hardie, 3-Jul-08, Discovering overlay networks and the resources found within in them presents a number of bootstrapping problems. While those hard problems are under discussion, this draft proposes a small set of mechanisms which are intended to be generically useful for providing pointers to peer-to-peer overlay networks in web pages, email messages, and other textual media. While the mechanisms described below each meet similar needs, they are not mutually exclusive; it is expected that each will find some useful deployment during the early days of peer-to-peer overlay deployment. "IPv6 in Broadband Networks", John Kaippallimalil, Frank Xia, 3-Jul-08, This document describes IPv6 link models and their applicability in a fixed broadband network architecture. This document also specifies the addressing and operation of IPv6 in broadband networks. The scope of this specification is limited to the operation of IPv6 in a broadband architecture. This includes the IPv6 link model, address configuration, router and neighbor discovery in broadband architecture. "Shelter Service And Classification", Qian Sun, Robins George, 3-Jul-08, This document defines a new service registration 'shelter', and describes how to find, what instances of shelter service are closest to the user's location. "RADIUS Over TCP", Alan DeKok, Intellectual Property, 3-Jul-08, The Remote Authentication Dial In User Server (RADIUS) Protocol has traditionally used the User Datagram Protocol (UDP) as it's underlying transport layer. This document defines RADIUS over the Transport Control Protocol (TCP). "MPLS-TP Requirements", Ben Niven-Jenkins, Deborah Brungard, Malcolm Betts, Nurit Sprecher, 3-Jul-08, This document specifies the requirements for a MPLS Transport Profile (MPLS-TP). This document is a product of a joint ITU-IETF effort to include a MPLS Transport Profile within the IETF MPLS architecture to support the capabilities and functionalities of a packet transport network as defined by ITU-T. This work is based on two sources of requirements, MPLS architecture as defined by IETF and packet transport networks as defined by ITU-T. "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", Quintin Zhao, Daniel King, Fabien Verhaeghe, Tomonori Takeda, Mohamad Chaitou, Jean-Louis Le Roux, Zafar Ali, 3-Jul-08, Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes extensions to the PCE Communication Protocol PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. "Lossless Compression for IP Flow Information Export (IPFIX)", Gerhard Muenz, Lothar Braun, 3-Jul-08, In this document, we discuss the benefits and possible realizations of IPFIX traffic compression. Experiments with real measurement data show that a significant compression gain can be achieved by applying the DEFLATE compression method to IPFIX data sets. Compression of IPFIX traffic can be based on underlying transport protocols, such as IPComp and TLS/DTLS, or realized as an extension of the IPFIX protocol. "MVPN: Optimized use of PIM, Wild Card Selectors, Bidirectional Tunnels", A Boers, Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 3-Jul-08, Specifications for a number of important topics were arbitrarily omitted from the initial MVPN specifications, so that those specifications could be "frozen" and advanced. The current document provides some of the missing specifications. The topics covered are: (a) using Wild Card selectors to bind multicast data streams to tunnels, (b) using Multipoint-to-Multipoint Label Switched Paths as tunnels, (c) binding bidirectional customer multicast data streams to specific tunnels, and (d) running PIM (i.e., sending and receiving multicast control traffic) over a set of tunnels that are created only if needed to carry multicast data traffic. "Multicast Control Extensions for ANCP", Philippe Champagne, Wojciech Dec, Sanjay Wadhwa, Stefaan De Cnodder, Roberta Maglione, 3-Jul-08, This draft is aimed at describing the ANCP protocol extensions required to support the NAS initiated ANCP Multicast Control use case described in ANCP framework draft. It proposes the definition of new ANCP message types, along with well known TLVs. "MPLS TP Network Management Requirements", Scott Mansfield, Kam Lam, Eric Gray, 8-Oct-08, This document specifies the network management requirements for supporting the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). Gray, et al Expires April, 2009 [page 1] Internet-Draft MPLS-TP NM Requirements October, 2008 "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", Young Lee, Dan Li, Wataru Imajuku, 3-Jul-08, A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. The information may be used in Generalized Multiprotocol Label Switching (GMPLS) signaling protocols, and may be distributed by GMSPL routing protocols. Other distribution mechanisms (for example, XML-based protocols) may also be used. This document provides efficient, protocol-agnostic encodings for the information elements necessary to operate a WSON. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", Mijeom Kim, JP Vasseur, Hakjin Chong, 4-Jul-08, This document specifies routing metrics used in path calculation for Routing Over Low power and Lossy networks (ROLL). Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired networks or even with similar ones such as mobile ad-hoc networks as indicated in several application-specific requirements documents. Since typical IGP routing metrics such as hop counts or link metrics are not sufficient for LLNs, this document specifies a new set of required link and node metrics suitable to LLNs. "ATN Topology Considerations for Aeronautical NEMO RO", Christian Bauer, Serkan Ayaz, 4-Jul-08, The intention of this draft is to provide an overview of the topology of the Aeronautical Telecommunications Network to help with the analysis of the possible options of NEMO RO within this context. The intention is to allow taking the existing NEMO RO solution space analysis document and cross-check it with the aeronautical environment presented within this document. "Updates to Referred-By in the Session Initiation Protocol (SIP).", Nadia Bishai, Salvatore Loreto, Adamu Haruna, 3-Jul-08, SIP has a mechanism for conveying the asserted identity of the originator of a request by means of the P-Asserted-Identity header field. When exploding a SIP MESSAGE request to a pre-defined group URI and when exploding a SIP INVITE request to an ad-hoc group or to a pre-defined group URI, the Referred-By header field in the resulting exploded requests is set to the P-Asserted-Identity header field or to the From header field. The Referred-By header is only included if the P-Asserted-Identity header field or From header field needs to carry another value, e.g. the URI of a pre-defined group, or a conference focus URI. Since the P-Asserted-Identity header field may carry up to two values, the Referred-By definition needs to be extended to allow up to two values as well. "Framework and Requirements for Virtual Private Multicast Service (VPMS)", Yuji Kamite, Frederic JOUNAY, Ben Niven-Jenkins, 13-Jul-08, This document provides a framework and service level requirements for Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer 2 VPN service that provides point-to-multipoint connectivity for a variety of Layer 2 link layers across an IP or MPLS-enabled PSN. This document outlines architectural service models of VPMS and states generic and high level requirements. This is intended to aid in developing protocols and mechanisms to support VPMS. "Management Information Base for the SEcure Neighbor Discovery (SEND) protocol", Alberto Garcia-Martinez, 4-Jul-08, This memo defines a portion of the Management Information Base (MIB) for managing the SEND (SEcure Neighbor Discovery) Protocol. "Management Information Base for Cryptographically Generated Addresses (CGA)", Alberto Garcia-Martinez, 4-Jul-08, This memo defines a portion of the Management Information Base (MIB) for managing Cryptographically Generated Addresses (CGA). "UDP-Encapsulated Transport Protocols", Remi Denis-Courmont, 4-Jul-08, This memo defines modified formats for conveyance of TCP and SCTP packets within UDP datagrams, to ease traversal of network address translators. "Application-Layer Traffic Optimization (ALTO) Requirements", Sebastian Kiesel, Laird Popkin, Stefano Previdi, Richard Woundy, Yang Yang, 4-Jul-08, Many Internet applications are used to access resources, such as server processes or pieces of information, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer filesharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one host out of several candidates for providing a desired resource. These recommendations shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to optimize performance (or Quality of Experience) in the application while minimizing resource consumption in the underlying network infrastructure. This document enumerates an initial set of requirements for ALTO and solicits feedback and discussion. "P2P Traffic Localization by Traceroute and 2-Means Classification", Yunfei Zhang, Liufei Wen, 14-Jul-08, Most P2P system performance suffers from the mismatch between the randomly constructed overlays topology and the underlying physical network topology, causing a large burden in the ISP and a long RTT time. This document describes how DHT overlay peers can interact with the routers by traceroute to get the path information, and execute 2- Means Classification, thereafter peers leverage the DHT itself to build efficient "closer" cluster. This scheme only requires the infrastructure to enable traceroute queries. "A Fast Handover Scheme in Proxy Mobile IPv6", Youn-Hee Han, Byungjoo Park, 4-Jul-08, This memo proposes a scheme that supports a fast handover effectively in Proxy Mobile IPv6 by optimizing the associated data and signaling flows during the handover. New signaling messages, Fast PBU and Reverse PBU, are defined and utilized to expedite the handover procedure. "Location Routing Function Requirements", Hadriel Kaplan, 4-Jul-08, This document describes the requirements for a Location Routing Function Protocol, for inter and intra-domain SIP session routing. "A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem", Volker Hilt, Ivica Rimac, Marco Tomsu, Vijay Gurbani, Enrico Marocco, 4-Jul-08, A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used traditionally for file-sharing, and more recently for real-time communications and live media streaming. Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. We refer to this as the Application Layer Traffic Optimization (ALTO) problem. In this draft we present a survey of existing literature on discovering topology characteristics. "The RKEY DNS Resource Record", Jim Reid, Jakob Schlyter, Ben Timms, 4-Jul-08, A DNS Resource record which can be used to encrypt NAPTR records is described in this document. "Scope-Extended Router Advertisement for Connected MANETs", Jaehwoon Lee, Sanghyun Ahn, Younghan Kim, 4-Jul-08, In the connected MANET, the MANET Border Router (MBR) is used to connect the MANET with the external network and MANET nodes are required to know the MBR address to communicate with hosts in the external network. One way of acquiring the MBR address is to use the Router Advertisement (RA) and the Router Solicitation (RS) messages. In order to allow RA/RS messages to be delivered in the multi-hop MANET, the modified RA/RS message has been defined [5]. However, this approach may incur the duplicate packet reception problem due to rebroadcasting of received RA/RS messages to its neighbors. In this draft, we define the scope-extended Router Advertisement/ Solicitation message for announcing/solicitating the MBR address in the connected MANET. In the scope-extended RA/RS message, a new message field, the sequence number field, is defined so that duplicate RA/RS messages can be detected based on the sequence number and the IP address included in the message. "P2P Traffic Localization by Alias Tracker for Tracker-based P2P applications (ATTP)", Yunfei Zhang, Hongluan liao, 14-Jul-08, Currently P2P applications have accounts for large cross-ISP traffic. This document proposes a method to reduce cross-ISP traffic by setting cooperative ISP-friendly trackers in the ISP's network. Through improving the random node selection mechanism in P2P tracker-based application, we can effectively reduce cross-ISP traffic as well as the cost of network equipments and network operation. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Cellular-based Central Control (CCC) Mechanism for Mobile Ad hoc Networks", Yunfei Zhang, 4-Jul-08, This document discusses a cellular based central control mechanism(CCC) for middle/small scale mobile Ad hoc networks. The proposed mechanism can be used for the mobile operators to build a central-controlled and manageable mobile Ad hoc network. "Lightweight DHCPv6 Relay Agent (LDRA)", David Miles, Sven Ooghe, Wojciech Dec, 4-Jul-08, This document proposes a lightweight DHCPv6 relay agent that can be implemented in existing access nodes (such as DSLAMs and Ethernet switches) that do not support IPv6 control or routing functions. "Secure DHCPv6 Using CGAs", Sheng Jiang, Sean Shen, 4-Jul-08, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks particularly fake attack. This document analyzes the security issues of DHCPv6 and specifies security mechanisms, mainly using CGAs. "Address Autoconfiguration for the subordinate MANET with Multiple MBRs", Jaehwoon Lee, Sanghyun Ahn, Younghan Kim, 5-Jul-08, In order to allow the subordinate MANET to be connected to the external network, the MANET border router (MBR) has been defined. For providing scalability and reliability to the subordinate MANET, multiple MBRs may be deployed. One of the issues on the subordinate MANET with multiple MBRs is which network prefixes are to be advertised by MBRs. In the case when MBRs advertise different network prefixes, if a MANET node changes its default MBR to a new one, the node may have to transmit packets via non-optimal paths to keep using the existing connection to the previous MBR, or change its address by using the network prefix information from the new MBR. In the latter case, on-going sessions can be terminated because of the address change. In this draft, we define a PMIPv6 based address autoconfiguration mechanism that enables MANET nodes to operate properly when all MBRs advertise the same network prefix in the subordinate MANET. "SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol", Michael Tuexen, Irene Ruengeler, Randall Stewart, 5-Jul-08, This document defines a method for a sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately. "Design Considerations for Session Initiation Protocol (SIP) Overload Control", Volker Hilt, 5-Jul-08, Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism. "Sieve Extension for converting messages before delivery", Alexey Melnikov, Qian Sun, 5-Jul-08, This document describes how Lemonade CONVERT can be used to transform messages before final delivery. "Expires: January 04, 2009 July 05, 2008", Zafar Ali, University Milan, University Milan, Cisco Systems, University Milan, University Milan, University Milan, 5-Jul-08, The problem of quality analysis and advanced fault detection of a pure light-path in a Dense Wavelength Division Multiplexing (DWDM) optical network requires the transmission of optical evidence related parameters along the provisioned route. In this draft we propose an RSVP-TE based mechanism to collect and evaluate optical evidence measured over optical nodes along the light-path. "Prefix-specific and Stateless Address Mapping (IVI) for IPv4/IPv6 Coexistence and Transition", Xing Li, Maoke Chen, Congxiao Bao, Hong Zhang, Jianping Wu, 5-Jul-08, This document presents the concept and practice of the prefix- specific and stateless address mapping mechanism (IVI) for IPv4/IPv6 coexistence and transition. In this scheme, subsets of the IPv4 addresses are embedded in prefix-specific IPv6 addresses and these IPv6 addresses can therefore communicate with the global IPv6 networks directly and can communicate with the global IPv4 networks via stateless (or almost stateless) gateways. The IVI scheme supports the end-to-end address transparency, incremental deployment and performance optimization in multi-homed environment. This document is a comprehensive report on the IVI design and its deployment in large scale public networks. Based on the IVI scenario, the corresponding address allocation and assignment policies are also proposed. "FIB Suppression with Virtual Aggregation and Default Routes", Paul Francis, Xiaohu Xu, Hitesh Ballani, 15-Sep-08, The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways. One of the most costly stresses is FIB size: ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB. FIB suppression is an approach to relieving stress on the FIB by NOT loading selected RIB entries into the FIB. This document specifies two styles of FIB suppression. Edge suppression (ES) allows ISPs that deploy a core- edge topology to shrink the FIBs of their edge routers, including those that interface to other ISPs and exchange the full DFRT. Virtual Aggregation (VA) allows ISPs to shrink the FIBs of any and all routers. Both styles may be deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP. "The WARC File Format (Version 0.16)", Sven Arvidson, John Kunze, Gordon Mohr, Michael Stack, 5-Jul-08, The WARC (Web ARChive) format specifies a method for combining multiple digital resources into an aggregate archival file together with related information. Resources are dated, identified by URIs, and preceded by simple text headers. By convention, files of this format are named with the extension ".warc" and have the MIME type application/warc. The WARC file format is a revision and generalization of the ARC format used by the Internet Archive to store information blocks harvested by web crawlers. This document specifies version 0.16 of the WARC format. "Graceful Shutdown of LDP Adjacency", Siva Sivabalan, Sami Boutros, Cisco Systems, 6-Jul-08, This document specifies an extension to Label Distribution Protocol (LDP) using which a Label Switched Router (LSR) can explicitly notify its neighbor LSR its intention to shutdown one or more LDP adjacencies. This extension shall be used to shutdown LDP adjacencies for planned maintenance without interrupting traffic. "The Model for Net and App Interaction", Ray Aatarashi, Megumi Ninomiya, 6-Jul-08, This document describes the model for application and network interaction in reaction to Application Area Architecture Workshop held on February 11 and 12, 2008. There is not completed mechanism for collaboration between application and network yet even though a solution is required. The model proposed in this document is designed without a layer violation. "The VLAN Model for Applications", Megumi Ninomiya, Ray Aatarashi, 6-Jul-08, This document describes the model for application and network interaction in reaction to Application Area Architecture Workshop held on February 11 and 12, 2008. There is not completed mechanism for collaboration between application and network yet even though a solution is required. The model proposed in this document is designed without a layer violation. This document propose the VLAN model for the application users. "Mapping of YANG to DSDL", Ladislav Lhotka, 6-Jul-08, This draft describes the algorithm and rules for mapping data models expressed in the YANG language to Document Schema Definition Languages (DSDL) with additional annotations. "Using EAP-GTC for Simple User Authentication in IKEv2", Yaron Sheffer, 6-Jul-08, Despite many years of effort, simple username-password authentication is still prevalent. In many cases a password is the only credential available to the end user. IKEv2 uses EAP as a sub-protocol for user authentication. This provides a well-specified and extensible architecture. To this day EAP does not provide a simple password- based authentication method. The only existing password authentication methods either require the peer to know the password in advance (EAP-MD5), or are needlessly complex when used within IKEv2 (e.g. PEAP). This document codifies the common practice of using EAP-GTC for this type of authentication, with the goal of achieving maximum interoperability. The various security issues are extensively analyzed. "IKEv2 based Mobile Network Prefix Assignment", Fan Zhao, Stefano Faccin, Ameya Damle, 6-Jul-08, This document proposes a mechanism for the Mobile Router to dynamically obtain the Mobile Network Prefix through IKEv2. The mechanisms to renew, release and update the allocated Mobile Network Prefixes are also described. "Using EAP keying material to derive keys for DHCP Authentication", Joseph Salowey, Richard Pruss, 6-Jul-08, This memo describes a mechanism to use keying material derived from the extensible authentication protocol (EAP) to derive cryptographic keys for authentication of the Dynamic Host Configuration Protocol (DHCP). Keys are derived from the EAP extended master session key (EMSK) and are used in a new DHCP authentication option based on the DHCP delayed authentication option defined in RFC 3118. "Problem Statement and Requirements for Diameter/Radius Prefix Authorization Application", Behcet Sarikaya, Frank Xia, 6-Jul-08, This document provides problem statement for AAA prefix authorization application. The document also identifies application scenarios and requirements on AAA prefix authorization application. "The References Header for SIP", Dale Worley, 6-Jul-08, This document defines a SIP extension header, References, to be used within SIP messages to signify that the message (and by extension, the dialog containing it) is related to one or more other dialogs. It is expected to be used largely for diagnostic purposes. "Practical Request for BGP Specification and Implementation", Yasuhiro Ohara, Kenichi Nagami, Akira Kato, 6-Jul-08, In 2007, a large scale incident have occurred multiple ISPs where a number of BGP sessions were disconnected. This happened because of the different implementation of BGP error handling. Therefore, it is necessary to classify the error processing of BGP to achieve stable operation of BGP, and to define it clearly. This document describes to clarify the classification of BGP error handlings. "Common TCP Evaluation Suite", Lachlan Andrew, Sally Floyd, 6-Jul-08, This document presents an evaluation test suite for the initial evaluation of proposed TCP modifications. The goal of the test suite is to allow researchers to quickly and easily evaluate their proposed TCP extensions in simulators and testbeds using a common set of well- defined, standard test cases, in order to compare and contrast proposals against standard TCP as well as other proposed modifications. This test suite is not intended to result in an exhaustive evaluation of a proposed TCP modification or new congestion control mechanism. Instead, the focus is on quickly and easily generating an initial evaluation report that allows the networking community to understand and discuss the behavioral aspects of a new proposal, in order to guide further experimentation that will be needed to fully investigate the specific aspects of a new proposal. "Path and Session Management in Proxy Mobile IPv6", Rajeev Koodli, Julien Laganier, 6-Jul-08, In a distributed network environment such as a Proxy Mobile IPv6 domain, it is often necessary to know that a peer is alive and, if not, detect quickly that a peer has failed and subsequently re- started. It is also necessary to detect failures where only a subset of the existing mobility sessions are affected. Furthermore, failure indication should be possible without waiting for an explicit query from a peer. This document outlines a protocol to address such path and session reliability for Proxy Mobile IPv6. "NAT for IPv6-Only Hosts", Cullen Jennings, 6-Jul-08, This specification defines a NAT that allows IPv6-only hosts that are inside the NAT to operate with IPv4 hosts that are outside the NAT. It requires no modifications to the v4 hosts or applications, or to the operating system of v6 hosts, but it does require some changes to v6 applications. Typically this specification would be used to allow the hosts inside a NAT to connect to hosts outside it; but under some limitations, it can also allow hosts outside to connect to hosts inside. The goal of this draft is to consider what is the minimal feasible approach to this problem. The draft is being discussed on the behave@ietf.org list. "DNS SRV Records for HTTP", Cullen Jennings, 6-Jul-08, This document specifies a mechanism for an HTTP client to perform a DNS SRV lookup to find an HTTP server. The draft is being discussed on the apps-discuss@ietf.org list. "HTTP API for Updating DNS Records", Cullen Jennings, 6-Jul-08, This specification defines a simple HTTP based scheme for clients to update DNS records. The draft is being discussed on the apps-discuss@ietf.org list. "Multicast Routing Blackhole Avoidance", Rajiv Asati, Mike McBride, 6-Jul-08, This document specifies a mechanism to avoid blackholing of IP Multicast traffic due to the disruption of multicast tree during the time when the RPF neighbor is yet to become the PIM neighbor. Such scenario is possible during the topology change (e.g. link UP) in an IP network that employs PIM-SM (or SSM) as the multicast routing protocol and a unicast routing protocol (including static routing). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "P2P Traffic Localization by Traceroute and 2-Means Classification", Liufei Wen, 4-Jul-08, Most P2P system performance suffers from the mismatch between the randomly constructed overlays topology and the underlying physical network topology, causing a large burden in the ISP and a long RTT time. This document describes how DHT overlay peers can interact with the routers by traceroute to get the path information, and execute 2-Means Classification, thereafter peers leverage the DHT itself to build efficient "closer" cluster. This scheme only requires the infrastructure to enable traceroute queries. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Effects of port randomization with TCP TIME-WAIT state.", Anantha Ramaiah, Patrick Tate, 6-Jul-08, Source port randomization has been suggested to provide improved security and obfuscation which helps in adding robustness towards blind attacks. With TCP in practice, simply producing a random port as the source port for a new connection can lead to problems when a TCP client establishes connections to a TCP server at a high rate. If the same source port value is chosen twice, the client TCP connection can fail due to the server having the Transmission Control Block (TCB) for this tuple lingering in TIME-WAIT state. This memo discusses the ramifications of such source port reuse scenarios and suggests some mitigations to avoid the same. "GMPLS RSVP-TE recovery extension for data plane initiated reversion", Attila Takacs, Benoit Tremblay, 14-Jul-08, RSVP-TE recovery extensions are specified in [RFC4872] and [RFC4873]. Currently these extensions cannot signal request for revertive protection to the remote endpoint. This document defines a new bit to signal this request and two new fields to specify a wait-to- restore and hold-off intervals. "A Presence Information Data Format - Location Object Extension for Triangulation Data", James Polk, 6-Jul-08, This document describes how a Presentity Agent (PA) provides a Location Information Server (LIS) with location specific measurement data it observes, for example - how many satellites are visible to a PA, and at what angle are each currently, to aid the LIS in determining geographically where the PA is. This is done within a Session Initiation Protocol subscription framework where the LIS subscribes to the PA for its measurement data. The LIS performs the location calculation, determining where the PA is. "Extending the Presence Information Data Format - Location Object (PIDF-LO) for Assisted Global Positioning System (A-GPS) Data", James Polk, Jay Iyer, 6-Jul-08, This document defines how a device encapsulates Assisted Global Positioning System (A-GPS) data to ask a Location Information Server (LIS) to calculate the device's position, and return that information to the device. This communication will be completed using the Session Initiation Protocol (SIP), using Presence Filters specific to A-GPS in a (SUBSCRIBE) request, and a Presence Information Data Format - Location Object (PIDF-LO) as the (NOTIFY) reply. "Session Initiation Protocol (SIP) Location Get Function", James Polk, 6-Jul-08, This document defines how a watcher seeks the geographic location information from presentity. SIP Location Conveyance defines how location is sent from one entity to another unsolicited. This document specifies how a watcher, i.e., a Location Target, requests for specific geolocation state information of a presentity, in addition to the details within the subscription such as the format (geo or civic) returned and the frequency of updated location from the presentity. "Sensor Network Routing Requirements of Structural Health Monitoring", Jaakko Hollmen, Jukka Manner, 6-Jul-08, This document discusses monitoring the status of constructions, structural health monitoring, using sensor networks, and the requirements such a system puts on routing. "Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment", Zafar Ali, 6-Jul-08, Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques described in [RFC4875]. However, [RFC4875] does not Expires August 2007 [page 1] draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt address many issues that comes when a P2MP-TE LSP is signaled in a multi-domain networks. Specifically, one of the issues in multi-domain networks is how to allow computation of a loosely routed P2MP-TE LSP such that it is remerge free. This document provides a framework and required protocol extensions needed for establishing and controlling P2MP MPLS and GMPLS TE LSPs in multi-domain networks. This document borrows inter-domain TE terminology from [RFC4726], e.g., for the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Requirements for IP Multicast Session Announcement in the Internet", Hitoshi Asaeda, Vincent Roca, 6-Jul-08, The Session Announcement Protocol (SAP) [3] was used to announce information for all available multicast sessions to the prospective receiver in an experimental network. It is usefull and easy to use, but difficult to control the SAP message transmission in a wide area network. This document describes the several major limitations SAP has and the requirement of multicast session announcement in the global Internet. "PIM/GRE Based MVPN Deployment Experience and Recommendations", Rahul Aggarwal, Yakov Rekhter, 6-Jul-08, Multicast VPN, based on the Virtual Router model using PIM with GRE tunnels, has been in operation in production networks for several years. This document describes some of the experiences gained from implementation and deployment of such Multicast VPNs. Further it describes the practices used by such deployments based on the experience. "Meta-Architecture : A Common Means to Accommodate Heterogeneous Network Architectures", Myung-Ki Shin, Eun Paik, JinHyeock Choi, 7-Jul-08, The today's Internet architecture is under serious reconsideration and people started thinking about alternatives. Redefining Internet architecture requires many challenged works and a lot of new heterogeneous architectures suited to the future of the Internet would be considered. It is necessary to support a variety of the new different architectures to accommodate the heterogeneity of Future Internet. So, a common means should be provided to accommodate the new heterogeneous architectures. This document presents Meta- Architecture to accommodate heterogeneous and diverse multiple network architecture and user services, for example, heterogeneous wireless, mobile, sensor, vehicular and/or ad-hoc architectures and services. "SIP SAML Profile and Binding", Andreas Pashalidis, Joao Girao, 7-Jul-08, This document specifies the SIP/SAML profile and binding, i.e. a protocol for the use of Security Assertion Markup Language (SAML) assertions for the purposes of authentication and the exchange of attributes in a Session Initiation Protocol (SIP) environment. "TWAMP Reflect Padding Feature", Al Morton, Len Ciavattone, 7-Jul-08, The IETF is completing its work on TWAMP - the Two-Way Active Measurement Protocol. This memo describes a proposed feature for TWAMP, intended for discussion in the IP Performance Metrics WG. The feature gives the reflector the ability to return some of the packet padding bits to the sender. "Multicast Pruning in Provider Backbone Bridged VPLS", Ali Sajassi, Luyuan Fang, Pradosh Mohapatra, Nabil Bitar, Raymond Zhang, 7-Jul-08, The scalability of H-VPLS (either with MPLS or Ethernet access network) can be improved by incorporating Provider Backbone Bridge (PBB) functionality in VPLS access. The ingress replication of PBB multicast traffic can be further improved by replicating such traffic over a subset of PWs for which there are receivers interested in that PBB multicast group. This document discusses the use of BGP for distribution of PBB multicast addresses (e.g., auto-discovery of these addresses) and applying multicast pruning to a VPLS instance for efficient ingress replication. "Multiprotocol Label Switching Transport Profile Survivability Framework", Nurit Sprecher, Adrian Farrel, Vach Kompella, 7-Jul-08, Network survivability is the network's ability to restore traffic following failure or attack; it plays a critical factor in the delivery of reliable services in transport networks. Guaranteed services in the form of Service Level Agreements (SLAs) require a resilient network that detects facility or node failures, very rapidly, and immediately starts to restore network operations in accordance with the terms of the SLA. The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet transport technology that combines the packet experience of MPLS with the operational experience of SONET/SDH. It provides survivability mechanisms such as protection and restoration, with similar function levels to those found in established transport networks such as in SONET/SDH networks. Some of the MPLS-TP protection mechanisms are data plane-driven and are based on MPLS-TP OAM fault management functions which are used to trigger protection switching in the absence of a control plane. Other protection mechanisms utilize the MPLS-TP control plane. This document provides a framework for MPLS-TP survivability. "Bulk DHCPv4 Lease Query", Kim Kinnear, Bernie Volz, Neil Russell, Mark Stapp, 7-Jul-08, The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a client to request information about DHCPv4 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. "Rich Template Set Extension to the IPFIX Protocol", Christoph Sommer, Falko Dressler, Gerhard Muenz, 7-Jul-08, This draft describes the Rich Template Set, a Template Set for the IPFIX Protocol, as well as its respective Template Records. One possible application domain for this new Set is the transport of IPFIX Flow Mediation selection criteria. In comparison to the use of Common Properties, the use of Rich Template Sets reduces the overhead of repeated transmissions and makes data transmissions more robust against failures. "Proxy Mobile IPv6 Management Information Base", Glenn Mansfield, Kazuhide Koide, Sri Gundavelli, Ryuji Wakikawa, 7-Jul-08, This memo defines a portion of the Management Information Base (MIB), the Proxy Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Proxy Mobile-IPv6 MIB will be used to monitor and control the mobile access gateway node and the local mobility anchor functions of a Proxy Mobile IPv6 (PMIPv6) entity. "New Care-of CGA Configuration for FMIPv6", David Hu, Chunqiang Li, 7-Jul-08, Fast Mobile IPv6 defines the necessary IP protocol messages to reduce the handover latency resulting from the Mobile IPv6 procedures. One of the important functionality is new care-of address configuration. This document introduces two possible methods for configuring NCoA based on CGA in FMIPv6. "IKEv2 SA Synchronization for session resumption", Yan Xu, Peng Yang, Yuanchen Ma, Hui Deng, Hui Deng, 7-Oct-08, It will take a long time and mass computation to do session resumption among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/IPsec SAs, when the serving gateway fails or over-loaded. The major reason is that the prcocedure of IKEv2 SA re-establishment will incur a time-consuming computation especially in the Diffie- Hellman exchange. In this draft, a new IKE security associations synchronization solution is proposed to do fast IKE SA session resumption by directly transferring the indexed IKE SA (named stub) from old gateway to new gateway, wherein the most expensive Diffie- Hellman calculation can be avoided. Without some time-consuming IKEv2 exchanges, the huge amount of IKE/IPsec SA session resumption procedures can be finished in a short time. "Camellia Cipher Suites for TLS", Akihiro Kato, Masayuki Kanda, Satoru Kanno, 15-Jul-08, This document specifies set of cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a block cipher algorithm. This proposal provides options for fast and efficient block cipher algorithms. "A Handover Authentication based on AAA server in FMIPv6", Jaeduck Choi, Doohwan Kim, Souhwan Jung, 7-Jul-08, This document describes a handover authentication protocol based on the AAA server in FMIPv6. The proposed scheme employs the Diffie- Hellman (DH) algorithm to enhance security aspects, and modifies the DH key exchange to reduce computational cost at the Mobile Node (MN) by delegating exponential operation to the AAA server. The MN and Access Router (AR) establish the handover key HK through the AAA server. The main advantage of this document is more secure and suitable to a light-weight mobile terminal. "The Extended GSS-API Negotiation Mechanism (NEGOEX)", Larry Zhu, Kevin Damour, Dave McPherson, 14-Jul-08, This document defines the Extended Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism (NegoEx). NegoEx is a pseudo-security mechanism that logically extends the SPNEGO protocol as defined in RFC4178. The NegoEx protocol itself is a security mechanism negotiated by SPNEGO. When selected as the common mechanism, NegoEx OPTIONALLY adds a pair of meta-data messages for each negotiated security mechanism. The meta-data exchange allows security mechanisms to exchange auxiliary information such as trust configurations, thus NegoEx provides additional flexibility than just exchanging object identifiers in SPNEGO. NegoEx preserves the optimistic token semantics of SPNEGO and applies that recursively. Consequently a context establishment mechanism token can be included in the initial NegoEx message, and NegoEx does not require an extra round-trip when the initiator's optimistic token is accepted by the target. Similar to SPNEGO, NegoEx defines a few new GSS-API extensions that a security mechanism MUST support in order to be negotiated by NegoEx. This document defines these GSS-API extensions. Unlike SPNEGO however, NegoEx defines its own way for signing the protocol messages in order to protect the protocol negotiation. The NegoEx message signing or verification can occur before the security context for the negotiated real security mechanism is fully established. "Problem Statement and Requirement of Simple IP Multi-homing of the Host", Min Hui, Hui Deng, 7-Jul-08, This document discusses current problems with simple IP multi-homing. In order to have deep understanding of the issue, the document also analyzes related works in IETF. In the end gives the requirements of the simple IP multi-homing in concern of technical implements. Simple IP multi-homing focuses on simultaneous multiple IP connections of the host. "MPLS-TP OAM Analysis", Nurit Sprecher, Thomas Nadeau, Huub Helvoort, Yaacov Weingarten, 7-Jul-08, The intention of this document is to analyze the set of requirements for OAM in MPLS-TP as defined in [MPLS-TP OAM Requirements], to verify whether the existing MPLS OAM tools can be applied to these requirements, identify which of the existing tools need to be extended, and which new tools should be defined. Eventually, the purpose of the document is to recommend which of the existing tools should be extended and what new tools should be defined to support the set of OAM requirements for MPLS-TP. "The requirement and proposal of extenting M3UA signalling network route management", Xu Chen, Hao Zhang, Xiaodong Duan, Zhao Yuyi, Li Xinyan, 7-Jul-08, RFC 4666 defines M3UA a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. M3UA is designed for SEP-(TDM)-SG-(IP)-IPSEP and IPSEP-(IP)-IPSEP applications, so the network level management function isn't required. But when M3UA is used in IP based signaling network, the network level management function needs to be extended. This document provides the proposals for extending M3UA signalling network route management. This document is consistent with RFC4666 in other sides. "Suggested process changes for handling new SIP headers and SIP responses", Keith Drage, 7-Jul-08, RFC 3427 currently defines the process for defining and registering new SIP header fields. This document proposes that prefixs to header field names should be discontinued, and that an additional category of experimental header field should be created. This document also relaxes the requirement that response codes are defined by standards track RFCs, also allowing them to be defined by experimental RFCs. "Best Current Practice for IP-based In-Vehicle Emergency Calls", Brian Rosen, Hannes Tschofenig, Ulrich Dietz, 15-Jul-08, This document describes how to use a subset of the IETF-based emergency call framework for accomplishing emergency calling support in vehicles. Simplifications are possible due to the nature of the functionality that is going to be provided in vehicles with the usage of GPS. Additionally, further profiling needs to be done regarding the encoding of location information. "Trustworthy Location Information", Hannes Tschofenig, Henning Schulzrinne, 7-Jul-08, For location-based applications, such as emergency calling or roadside assistance, the identity of the requestor is less important than accurate and trustworthy location information. A number of protocols are available to supply end systems with either civic or geodetic information. For some applications it is an important requirement that location information has not been modified in transit or by the end point itself. This document investigates different threats, the adversary model, and outlines three possible solutions. The document concludes with a suggestion on how to move forward. "A Session Initiation Protocol (SIP) Event Package for Location Information", James Winterbottom, Martin Thomson, Hannes Tschofenig, 7-Jul-08, This document specifies a SIP event package allowing allowing a location receiptient to subscribe for location information when provided a location URI using the sip, sips, or pres URI schemes. The notification that results from the subscription is either the location of the Target or an error. "MPLS-TP OAM Analysis", Nurit Sprecher, Thomas Nadeau, Huub Helvoort, Yaacov Weingarten, 3-Sep-08, The intention of this document is to analyze the set of requirements for OAM in MPLS-TP as defined in [MPLS-TP OAM Requirements], to verify whether the existing MPLS OAM tools can be applied to these requirements, identify which of the existing tools need to be extended, and which new tools should be defined. Eventually, the purpose of the document is to recommend which of the existing tools should be extended and what new tools should be defined to support the set of OAM requirements for MPLS-TP. "Link properties advertisement from modem to router", Lloyd Wood, Rajiv Asati, Daniel Floreani, 14-Jul-08, Routers are increasingly connected to a variety of smart modems. Such a modem's incoming and outgoing link rates can be varied over time with adaptive coding and modulation to suit the channel characteristics. The link rate and conditions offered by the modem to connected devices therefore vary. For connected devices to condition traffic and get the most out of the modem's link capacity, they need to know the modem's link conditions. This document describes one simple method for the modem to advertise link rate and other characteristics, via UDP messages, and discusses alternative approaches to communicating this information. "Independent Session Control Feature for TWAMP", Al Morton, 7-Jul-08, The IETF is completing its work on TWAMP - the Two-Way Active Measurement Protocol. This memo describes a proposed feature for TWAMP, intended for discussion in the IP Performance Metrics WG. The feature gives the sender the ability to start and stop one or more test sessions using the Session Identifiers. "Why should the Traffic Optimization not be restricted to the Application-Layer?", Damien Saucez, Dimitri Papadimitriou, 7-Jul-08, The Application-Layer Traffic Optimization (ALTO) problem is being discussed within the IETF and more globally by the research community and some enterprises. In this memo, we argue that it is important to conceive general-purpose mechanisms to solve this problem. By general-purpose we say not only application independent but also layer independent mechanism. The generality can be obtained because the underlying problem is the same regardless the application or the layer. "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", Jari Arkko, Vesa Lehtovirta, Pasi Eronen, 12-Oct-08, This specification defines a new EAP method, EAP-AKA', a small revision of the EAP-AKA method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1. This specification also updates RFC 4187 EAP-AKA to prevent bidding down attacks from EAP-AKA'. "A Uniform Resource Name (URN) Namespace for CableLabs", Eduardo Cardona, Sumanth Channabasappa, Jean-Francois Mule, 6-Jul-08, This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by Cable Television Laboratories Inc. (CableLabs). CableLabs publishes specifications that define unique and persistent resources that make use of the cablelabs URN namespace. "TCP Flow Control for Fast Startup Schemes", Michael Scharf, Sally Floyd, Pasi Sarolahti, 7-Jul-08, This document describes extensions for the flow control of the Transmission Control Protocol (TCP) that avoid interactions with fast startup congestion control mechanisms, in particular the Quick-Start TCP extension. Quick-Start is an optional TCP extension that allows to start data transfers with a large congestion window, using feedback of the routers along the path. This can avoid the time consuming Slow-Start, provided that the TCP flow control is not a limiting factor. There are two potential interactions between the TCP flow control and congestion control schemes without the standard Slow-Start: First, receivers might not allocate a sufficiently large buffer space after connection setup, or they may advertise a receive window implicitly assuming the Slow-Start behavior on the sender side. This document therefore provides guidelines for buffer allocation in hosts supporting the Quick-Start extension. Second, the TCP receive window scaling mechanism can prevent fast startups immediately after the initial three-way handshake connection setup. This document describes a simple solution to overcome this problem. "OSPFv3 as a PE-CE routing protocol", Padma Pillay-Esnault, Peter Moyer, Jeff Doyle, Emre Ertekin, Michael Lundberg, 7-Jul-08, Many Service Providers (SPs) offer the Virtual Private Network (VPN) services to their customers, using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. "Monitoring Architectures for RTP", Geoff Hunt, Philip Arden, 7-Jul-08, This memo is intended to stimulate discussion on a hierarchical monitoring architecture for RTP, including a scheme for the definition of lower-layer metrics which are usable by a range of applications. Systematic investigation of a monitoring architecture for RTP/RTCP was requested at the IETF71 (Philadelphia) AVT session. This first version of the draft is restricted to transport metrics and to a subset of audio application metrics, but it is envisaged that future work should extend this to other applications, principally video. "Issues with overlapping IPv6 fragments", Suresh Krishnan, 13-Jul-08, The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. "SRTP Store and Forward", Rolf Blom, Yi Cheng, Fredrik Lindholm, John Mattsson, Mats Naslund, Karl Norrman, 7-Jul-08, The Secure Real-time Transport Protocol (SRTP) transforms were designed to allow simple and efficient protection of RTP. To provide this, encryption and authenticity of media and control signaling are tightly coupled to the RTP session, and to the information in the RTP header. Hence, it is not possible to perform store and forward of protected media. This document gives, based on a use case analysis, requirements that new SRTP transforms need to satisfy in order to allow independent media and transport protection. A first proposal on how to implement such transforms in SRTP is also presented. "JWT Report on MPLS Architectural Considerations for a Transport Profile", Stewart Bryant, Loa Andersson, 7-Jul-08, This RFC archives the report of the IETF - ITU-T Joint Working Team (JWT) on the application of MPLS to Transport Networks. The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM, survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process. There are two versions of this RFC. An ASCII version that contains a summary of the slides and a PDF version that contains the summary and a copy of the slides. "Inter-Domain Handover and Data Forwarding between Proxy Mobile IPv6 Domains", Niklas Neumann, Xiaoming Fu, Jun Lei, Gong Zhang, 7-Jul-08, This document specifies mechanisms to setup and maintain handover and data forwarding procedures that allow a mobile node to move between different domains that provide (localized) network-based mobility support based on Proxy Mobile IPv6 for that node. "A Session Initiation Protocol (SIP) Load Control Event Package", Charles Shen, Henning Schulzrinne, Arata Koike, 7-Jul-08, This document defines a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute user load control information to SIP servers. The load control information can throttle outbound calls based on their destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. "The Global HAHA Operation at the Interop Tokyo 2008", Ryuji Wakikawa, Keiichi Shima, Noriyuki Shigechika, 7-Jul-08, This document describes the protocol design consideration of the correspondent router for the NEMO Basic Support Protocol. "The Design Consideration of Correspondent Router", Ryuji Wakikawa, 7-Jul-08, This document describes the protocol design consideration of the correspondent router for the NEMO Basic Support Protocol. "NEMO Basic Support for Fixed Access Networks", Ryuji Wakikawa, Shin Miyakawa, 7-Jul-08, This document describes the usage of Network Mobility (NEMO) for the commercial ISPs. NEMO can be a mechanism to provide IP subscription. "Marking Converter for Excess-Marked Traffic", Michael Menth, Frank Lehrieder, 7-Jul-08, This document proposes an algorithm that converts packet markings of a stream that was excess-marked based on a lower-rate into packet markings that correspond to a stream that was excess-marked based on a higher-rate. It may be applied in the PCN context to convert marked admissible-rate-overload into marked supportable-rate- overload. This allows to perform marked flow termination when packets are excess-marked based on the admissible rate only. "End-to-End Identity Important in the Session Initiation Protocol (SIP)", John Elwell, 7-Jul-08, This document surveys existing mechanisms in the Session Initiation Protocol (SIP) for identifying and authenticating the source of a SIP request (or caller identification). It describes how identification and authentication are not always end-to-end and the problems that this can lead to, particularly since media security based on techniques such as DTLS-SRTP is dependent on end-to-end authenticated identification of parties. This work is being discussed on the sip@ietf.org mailing list. "RUCUS Test Cases", David Schwartz, 7-Jul-08, This document is meant to serve as a repository for test cases assoicated with taking some action upon receipt of unwanted communications. "A way for a host to indicate support for 240.0.0.0/4 addresses", Teemu Savolainen, 7-Jul-08, This document describes how the 240.0.0.0/4 address space can be taken into use in incremental and backwards compatible manner in certain networks, and how reclassification of 240.0.0.0/4 address space as private would help Internet growth and transition to IPv6. "IPv4 support in PMIP-MIP interaction", Desire Oulai, Suresh Krishnan, 7-Jul-08, PMIPv6 and MIPv6 are respectively the leading protocols for network based and client based mobility. As backward compatibility is an important feature, IPv4 support for PMIPv6 and MIPv6 becomes mandatory. This document highlights some scenarios for PMIPv6-MIPv6 interaction with IPv4 support as well as some proposed solutions. "Key Data for a Registry Provisioning Interface draft-guyton-drinks-registry-data-00.txt", Debbie Guyton, 7-Jul-08, This document defines data that should be included in a provisioning interface for a Registry. The provisioning interface may be used in (near) real time, or periodically, from a service provider's service provisioning system to establish and administer telephone number (TN) and associated routing information in the Registry after necessary validations. Based on 1) effective date/time specified for the data and 2) validation of the TN assignee, these data will be used to define selective routing views for various recipient service providers which would be reflected in ENUM-SIP address servers. In addition, the concept of multiple TNs sharing a common routing pattern simplifies the definition and administration of routing data. D. Guyton Expires 01/07/09 [page 1] Registry Provisioning Interface July 2008 "Local Forwarding in Proxy Mobile IPv6", Rajeev Koodli, Kuntal Chowdhury, 7-Jul-08, With bidirectional tunneling in Proxy Mobile IPv6, the communication between any two Mobile Nodes is required to traverse the Local Mobility Anchor (LMA). This is the case even when the communicating Mobile Nodes are attached to the same Mobility Anchor Gateway (MAG). This document introduces two messages between the LMA and the MAG enabling local forwarding by the MAG. Such forwarding avoids the delay due to bidirectional forwarding, and reduces the traffic load on the LMA. "Bulk Re-registration for Proxy Mobile IPv6", Domagoj Premec, Basavaraj Patil, Suresh Krishnan, 14-Jul-08, The Proxy Mobile IPv6 specification requires the Mobile Access Gateway (MAG) to send a separate Proxy Binding Update (PBU) message to the Local Mobility Agent (LMA) for each mobile node (MN) to renew the MN's mobility binding. This document defines a mechanism by which a MAG can update the mobility bindings of multiple MNs attached to it with a single PBU message to the serving LMA. This mechanism is also intended to be used by a MAG to re-establish bindings at a new LMA when its old LMA fails. "Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework", Ulas Kozat, Ali Begen, 7-Jul-08, This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the FEC Framework document and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-pledged protocol, but to show how the defined framework and SDP elements can be combined together to design a CDP. "Problem Statement: Link Degradation Isolation in Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", Zhenqiang Li, Lianyuan Li, Xiaodong Duan, 7-Jul-08, IS-IS protocol specifies a procedure that if a Link State Protocol Data Unit (LSP) with an incorrect LSP Checksum is received, the corruptedLSPReceived circuit event will be generated and the corrupted LSP will be discarded. This document aims to emphasize that although this procedure can maintain the network stability, it can not diagnose and isolate the source of the network problem. In some cases this procedure will create bad effect on the services carried by the network. This document suggests that IS-IS protocol introduce the mechanism for link degradation detection and isolation, which should be triggered when corrupted LSP is received. "Mobile IPv6 Route Optimisation for Network Mobility (MIRON)", Carlos Bernardos, Maria Calderon, Ignacio Soto, 7-Jul-08, The Network Mobility Basic Support protocol enables networks to roam and attach to different access networks without disrupting the ongoing sessions that nodes of the network may have. By extending the Mobile IPv6 support to Mobile Routers, nodes of the network are not required to support any kind of mobility, since packets must go through the Mobile Router-Home Agent (MRHA) bi-directional tunnel. Communications from/to a mobile network have to traverse the Home Agent, and therefore better paths may be available. Additionally, this solution adds packet overhead, due to the encapsulation. This document describes an approach to the Route Optimisation for NEMO, called Mobile IPv6 Route Optimisation for NEMO (MIRON). MIRON enables mobility-agnostic nodes within the mobile network to directly communicate (i.e. without traversing the MRHA bi-directional tunnel) with Correspondent Nodes. The solution is based on the Mobile Router performing the Mobile IPv6 Route Optimisation signalling on behalf of the nodes of the mobile network. This document (in an appendix) also analyses how MIRON fits each of the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. "Teredo Extensions", Dave Thaler, 14-Jul-08, This document specifies a set of extensions to the Teredo protocol. These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs), and support for more efficient communication. "Correspondent Router based Route Optimisation for NEMO (CRON)", Carlos Bernardos, Maria Calderon, Ignacio Soto, 7-Jul-08, The Network Mobility Basic Support protocol enables networks to roam and attach to different access networks without disrupting the ongoing sessions that nodes of the network may have. By extending the Mobile IPv6 support to Mobile Routers, nodes of the network are not required to support any kind of mobility, since packets must go through the Mobile Router-Home Agent (MRHA) bi-directional tunnel. Communications from/to a mobile network have to traverse the Home Agent, and therefore better paths may be available. Additionally, this solution adds packet overhead, due to the encapsulation. This document describes an approach to the Route Optimisation for NEMO, based on the well-known concept of Correspondent Router. The solution aims at meeting the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. Based on the ideas that have been proposed in the past, as well as some other extensions, this document describes a Correspondent Router based solution, trying to identify the most important open issues. The main goal of this first version of the document is to describe an initial NEMO RO solution based on the deployment of Correspondent Routers and trigger the discussion within the MEXT WG about this kind of solution. This document (in an appendix) also analyses how a Correspondent Router based solution fits each of the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. "BGP Class of Service Interconnection", Thomas Martin Knoll, 7-Jul-08, This document focuses on Class of Service Interconnection at inter- domain peering points. It specifies two new non-transitive attributes, which enable adjacent peers to signal Class of Service Capabilities and certain Class of Service admission control Parameters. The new "CoS Capability Attribute" is deliberately kept simple and denotes the general EF, AF Group and BE forwarding support across the advertising AS. The second "CoS Parameter Attribute" is of variable length and contains a more detailed description of available forwarding behaviours using the PHB id Code encoding. Each PHB id Code is associated with rate and size based traffic parameters, which will be applied in the ingress AS Border Router for admission control purposes to a given forwarding behaviour. The denoted Class of Service forwarding support is meant as the AS externally available (transit) Class of Service support. "GDOI Generic Message Authentication Code Policy", Brian Weis, Sheela Rowles, 7-Jul-08, A number of IETF signaling and routing applications require a set of devices to share the same policy and keying material and include a message authentication code in their protocols packets for authentication . It is often beneficial for this keying material to be chosen dynamically using a group key management protocol. This memo describes the policy required for the Group Domain of Interpretation (GDOI) group key management system to distribute a message authentication code key and associated policy. "Datagram Transport Layer Security for Stream Control Transmission Protocol", Michael Tuexen, Robin Seggelmann, Eric Rescorla, 7-Jul-08, This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP). The user of DTLS over SCTP can take advantage of all features provided by SCTP and its extensions, especially support of o multiple streams to avoid head of line blocking. o multi-homing to provide network level fault tolerance. o unordered delivery. o partial reliable data transfer. "The Use of Entropy Labels in MPLS Forwarding", Kireeti Kompella, Shane Amante, 7-Jul-08, Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the notion of "entropy labels". It defines the concept, describes why they are needed, suggests how they can be used, and enumerates properties of entropy labels that allow optimal benefit. "Raptor FEC Schemes for FECFRAME", Mark Watson, 7-Jul-08, This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor code and its application to reliable delivery of media streams in the context of FEC Framework. The Raptor code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor code offers a close to optimal protection against arbitrary packet losses at a low computational complexity. Two FEC Schemes are defined, one for protection of arbitrary packet flows and another for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. An RTP Payload Type is defined for this latter case. "Unicast-Based Rapid Synchronization with RTP Multicast Sessions", Bill Steeg, Ali Begen, Tom Caenegem, 7-Jul-08, When a receiver joins a multicast session, it may need to acquire and parse certain key information before it can process any data sent in the multicast session. Depending on the join time, length of the key information repetition interval, size of the key information as well as the application and transport properties, the time lag before a receiver can usefully consume the multicast data, which we refer to as the synchronization delay, varies and may be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts. In this document, we describe a method using existing RTP and RTCP protocol machinery that reduces the synchronization delay. In this method, an auxiliary unicast RTP session carrying the key information to the receiver precedes/accompanies the multicast flow. This unicast flow may be transmitted at a faster than natural rate to further accelerate the synchronization. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, the proposed method can also be used in other types of multicast applications where the synchronization delay is long enough to be a problem. "TICTOC Requirement", Silvana Rodrigues, Kurt Lindqvist, 7-Jul-08, Distribution of high precision time and frequency over the Internet and special purpose IP networks is becoming more and more needed as IP networks replace legacy networks and applications and as new applications with need for frequency and time are developed on the Internet. The IETF formed the TICTOC workinggroup to address the problem and perform an analysis on existing solutions and the needs. This document summarises application needs, as described and agreed on at an TICTOC interim meeting held in Paris from June 16 to 18, 2008. "Generic Ethernet Pseudowire", Shane Amante, Giles Heron, Andrew Malis, Vach Kompella, Florin Balus, 15-Jul-08, This draft proposes a simpler approach to handling various encapsulations of Ethernet packets over a pseudowire, over the existing Ethernet Pseudowire definition in [RFC4448]. "PathErr Message Triggered MPLS and GMPLS LSP Reroute", Lou Berger, Dimitri Papadimitriou, JP Vasseur, 7-Jul-08, This document describes how Resource ReserVation Protocol (RSVP) PathErr Messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may desirable in a number of cases including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms and defines no new formats or mechanisms. It relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. "NETCONF Notification Content", Sharon Chisholm, Alex Clemm, Malcolm Betts, 7-Jul-08, The NETCONF Event Notifications standard specifies the mechanism by which NETCONF clients can subscribe to and receive event notifications. However, with the exception of a timestamp, no standard Notification content was defined. This memo defines a set of information that should be included in all NETCONF notifications, information that should be included based on class of notification and also defines a set of specific notifications to support specific management functions, such as configuration. "Requirements for OAM in MPLS Transport Networks", Martin Vigoureux, David Ward, Malcolm Betts, Matthew Bocci, Italo Busi, 7-Jul-08, This document specifies requirements for OAM (Operations and Management) functionality in MPLS networks that are used for packet transport services and network operations. The use of the term MPLS in this document refers to both MPLS PSNs and pseudowire technologies. These requirements are derived from the set of requirements specified by ITU-T and first published in the ITU-T Supplement Y.Sup4 [6]. "PCN Encoding for Packet-Specific Dual Marking (PSDM)", Michael Menth, Jozef Babiarz, T Moncaster, Bob Briscoe, 7-Jul-08, This document proposes how PCN marks can be encoded into the IP header. The presented encoding reuses the ECN field of the Voice- Admit DSCP in a single PCN domain. The encoding of unmarked PCN packets indicates whether they are subject to either excess- or exhaustive-marking. This is useful, e.g., when data and probe packets require different marking mechanisms. Status This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC. "A Framework for MPLS in Transport Networks", Matthew Bocci, Marc Lasserre, Dieter Beller, Italo Busi, Stewart Bryant, 7-Jul-08, There is a requirement to use MPLS to provide a network layer to support packet transport services. It is desirable that the operation and maintenance of such an MPLS based packet transport network follow operational models typical in optical transport networks, while providing additional OAM, survivability and other maintenance functions not currently supported by MPLS. This draft presents a framework for an architectural and functional profile of MPLS in order to support packet transport services. "Private Extensions to the Session Initiation Protocol (SIP) for Asserter Identification within Trusted Networks", Hadriel Kaplan, 7-Jul-08, This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to identify the asserter of private user identity defined in RFC 3325. The use of these extensions is only applicable inside a set of administrative domains with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general identity model suitable for use between different trust domains, or use in the Internet at large. "Simplified VPLS-PBB interworking via MMRP", David Allan, Nigel Bragg, Dinesh Mohan, 7-Jul-08, This document describes how MAC filtering programmed by the IEEE multiple MAC registration protocol (MMRP or 802.1ak) can be employed by VPLS-PE devices as the exclusive mechanism for interworking with 802.1ah PBBNs. No new protocol standardization is required to do this, however there are small procedural changes associated with the interworking of protocols. "DHCPv4 Vendor-specific Message", Bernie Volz, 7-Jul-08, This document requests a vendor-specific DHCPv4 message assignment. This message can be used for vendor specific and experimental purposes. "Mobile IPv6 Generic Signaling Message", Brian Haley, Sri Gundavelli, 11-Jul-08, This document specifies two new Mobility Header message types that allow Mobile IPv6 entities to send and receive generic signaling messages. Haley Expires - December 2008 [page 1] Mobile IPv6 Generic Signaling Message July 2008 "Uses of policy control in routing", Anne-Louise Burness, 7-Jul-08, When considering a new routing system, we need to ensure that it is able to meet the functionality requirements of the participant networks. One aspect that is frequently over-looked is that routing is rarely a simple matter of choosing a least-hop path. This document attempts to highlight some of the more common policy choices that are made. We expect that policies that are in common use today should be easy to implement with any new routing schemes. Any routing scheme make it possible or significantly easier to implement the harder policies would have an implementation advantage. "Enhanced BGP Capabilities for Exchanging Second-Best Paths", Brian Dickson, 13-Jul-08, This Internet Draft describes an enhanced format for encoding prefix information, to permit multiple copies of a prefix with different paths to be announced and withdrawn. Prefix instances using the new format include both unique identifiers, and ordinals to control path selection. Withdrawal of prefixes requires a slight modification to disambiguate prefix instances.Author's Note This Internet Draft is intended to result in this draft or a related draft(s) being placed on the Standards Track for idr. "Enhanced BGP Capabilities for Exchanging Additional Nth-Best Paths", Brian Dickson, 13-Jul-08, This Internet Draft describes an enhanced way to exchange prefix information, so as to permit multiple copies of a prefix, with different paths, to be announced and withdrawn. This negotiated capability facilitates faster local (inter-AS) and global (intra-AS) convergence, reduces path-hunting, improves route- reflector behaviour, including eliminating persistent oscillations. Additional prefix instances have a new wire format for updates and withdrawals, to control path selection. Benefits are seen both when deployed intra-AS, and on inter-AS peering. Author's Note This Internet Draft is intended to result in this draft or a related draft(s) being placed on the Standards Track for idr. "End-to-end Extension for PCN Encoding", Michael Menth, Jozef Babiarz, T Moncaster, 7-Jul-08, This document proposes an encoding of PCN marks based on the ECN field of the Voice-Admit DSCP. It has global meaning and ECN semantics are not applied to that field. The PCN codepoints are the same as those for packet-specific dual marking (PSDM) within a single PCN domain, but the general concept can also be applied to other encodings requiring only a single PCN-enabled DSCP. "Evolution of the IP Model", Dave Thaler, 14-Jul-08, This draft attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, and especially properties which were (and at times still are) incorrectly perceived to exist, as well as properties that changing would cause problems. "Opaque MSRP Path Uri", Derek MacDonald, Hadriel Kaplan, 7-Jul-08, The Message Session Relay Protocol(MSRP) does not allow efficient topology hiding, such that MSRP users can hide the IP Address of their systems. This limitation is due to the fact that MSRP Path headers contain physical IP addresses. This document describes a mechanism which adds a level of indirection to allow topology hiding. It defines the option tag msrp-opaque. "Datagram Transport Layer Security Transport Model for SNMP", Wesley Hardaker, 7-Jul-08, This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides authentication and privacy services for SNMP applications. This document describes how the DTLS Transport Model (DTLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators, operate in environments where a connectionless (UDP) transport is preferred, and integrates well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for monitoring and managing the DTLS Transport Model for SNMP. "Context-based Header Compression for 6lowpan", Carsten Bormann, 7-Jul-08, 6lowpan (RFC 4944) so far has only defined stateless forms of header compression. This document specifies how a node and a router can agree on state that will allow much better header compression of global addresses. $Id: draft-bormann-6lowpan-cbhc.xml,v 1.2 2008/07/07 22:19:28 cabo Exp $ "EDNS Option Code for Private Opaque Text", Hadriel Kaplan, Robert Walter, Raja Gopal, Tom Creighton, 7-Jul-08, This document requests an IANA allocation for an EDNS Option code, per [RFC2671], for an opaque text field for private use. "IP Flow Anonymisation Support", Elisa Boschi, Brian Trammell, 14-Jul-08, This document describes anonymisation techniques for IP flow data. It provides a categorization of common anonymisation schemes and defines the parameters needed to describe them. It describes support for anonymization within the IPFIX protocol, providing the basis for the definition of information models for configuring anonymisation techniques within an IPFIX Metering or Exporting Process, and for reporting the technique in use to an IPFIX Collecting Process. "An Extension to the Presence Information Data Format - Location Object (PIDF-LO) for the Timezone of a Presentity", James Polk, Jonathan Rosenberg, 7-Jul-08, The Presence Information Data Format - Location Object (PIDF-LO) lacks an indication for the timezone offset of a particular presentity is in. This document extends the PIDF-LO for including such an XML element. "Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples", Mary Barnes, Chris Boulton, Lorenzo Miniero, Simon Romano, 7-Jul-08, This document provides detailed call flows for the scenarios documented in the Centralized Conferencing (XCON) Framework and the XCON Scenarios. The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP). The objective is to provide a base reference for both protocol researchers and developers. "Nominating Committee Process: Issues since RFC 3777", Spencer Dawkins, Danny McPherson, 7-Jul-08, This document describes issues with the current IETF Nominating Committee process that have arisen in practice. "AS4-specific RD/RT/SOO Capability exchange", Samita Chakrabarti, 7-Jul-08, RFC 4893 defines BGP support for four-octet AS number space for handling AS_PATH attributes and "My ASN" value in BGP OPEN messages. Foue-Octet AS specific Extended Community attribute formats are defined in draft-rekhter-as4octet-ext-community-03.txt. However, an implementation compliant to RFC 4893 does not necessarily provide support for 4-Octet Route-distinguisher, Route-target or Site-of- origin in the BGP-MPLS-VPN. Thus BGP capability exchange for extended AS number attribute does not cover the BGP-MPLS-VPN AS4- specific route-attributes and route-distinguishers. This document proposes an optional BGP capability exchange between the Provider Edge (PE) routers in order to communicate the intention of handling 4-Octet or 2-Octet exteneded AS-specific Route-targets or Site-of- Origins or being able to handle and inteprete the 4-Octet route- distinguishers correctly. This capability parameter will be part of OPEN message during the BGP session initiation. "The Importance of a Visual Identifier of Trusted Identity", Dan York, 7-Jul-08, This document discusses the need for a visual identifier in Session Initiation Protocol (SIP) endpoints to indicate to the end user that they are speaking with someone whose identity is trusted. "Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)", Marc Petit-Huguenin, 14-Jul-08, This document describes a Session Traversal Utilities for NAT (STUN) usage for discovering the path MTU between a client and a server. "PBS NSLP: Network Traffic Authorization", Se Gi Hong, Henning Schulzrinne, 14-Jul-08, This document describes the NSIS Signaling Layer protocol (NSLP) for network traffic authorization in the Internet, the Permission-Based Sending (PBS) NSLP. This NSLP aims to prevent Denial-of-Service (DoS) attacks and other forms of unauthorized traffic. In the PBS NSLP, a receiver grants a sender a permission that gives the sender the authority to send data. Signaling installs and maintains the permission state of routers for a data flow. The PBS NSLP has a detection algorithm, the PBS Detection Algorithm (PDA), that monitors attacks. To authenticate packets, the PBS NSLP requests a sender to use an existing security protocol, the IPsec Authentication Header (AH). This allows routers to drop bogus packets by using an IP packet filter. To avoid a compromised router that drops legitimate packets, the PBS NSLP triggers the sender to change the data flow path. "Signaled PID When Multiplexing Multiple Payloads over RSVP-TE LSPs", Zafar Ali, 7-Jul-08, There are many deployment scenarios where an RSVP-TE LSP carries multiple payloads. In these cases, it gets ambiguous on what should value should be carried as L3PID in the Label Request Object [RFC3209] or G-PID in the Generalized Label Request Object Expires January 2009 [page 1] draft-ali-mpls-sig-pid-multiplexing-case-00.txt [RFC3471], [RFC3473]. The document propose use of some dedicated PID values to cover some typical cases of multiple payload carried by the LSP, including that indicates to the egress node to ignore signaling to learn payload carried by the LSP. "IPv4 ID Uniqueness Requirements", Joseph Touch, Matt Mathis, 7-Jul-08, The IPv4 Identification field enables fragmentation and reassembly. This document clarifies the meaning of this field in the absence of fragmentation, based on ubiquitous current practice. "Tunnels in the Internet Architecture", Joseph Touch, Mark Townsley, 7-Jul-08, This document discusses the role of tunnels in the Internet architecture. It explains their relationship to existing protocol layers, and the challenges in supporting tunneling. "The Location "On Behalf Of" Model is Broken", Marc Linsner, 7-Jul-08, There is proposed solution submitted to the GeoPriv work group that outlines the need for a location recipient to obtain the location of a target without the target's knowledge. The scenario is described as supporting a legacy device (a device lacking support for location) for the purposes of utilizing location when the legacy device summons emergency help (by dialing 911/112, etc.). Below is a discussion of the of the general topic of discovering location via 'On Behalf Of' or OBO. "Requirements of One-way Passive Measurement for End-to-End Quality", Yutaka Kikuchi, Satoru Matsushima, Kenichi Nagami, Satoshi Uda, 7-Jul-08, This draft describes the necessary requirements to passively measure end-to-end quality and to monitor them via applicable ways. This feature is crucial for Service Providers (SPs), especially who provide transports with Service Level Agreements (SLAs). "On the Relative Importance of P2P Peer Selection", Patrick Crowley, 7-Jul-08, This Internet-draft discusses the relative importance of path selection in peer-to-peer (P2P) applications in light of the recent discussions highlighting the conflict between the use of P2P applications and the costs borne by network infrastructure operators. "Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process", Robert Cole, Joseph Macker, Brian Adamson, 7-Jul-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process. The SMF MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting multicast forwarding problems. "Transport for Advanced Networking Applications (TANA) Problem Statement", Stanislav Shalunov, 14-Jul-08, The IETF P2PI workshop conducted in the end of May 2008 at MIT in Boston has identified a number of potential documents for the IETF to work on. One is a transport protocol with congestion control mechanism that enables an advanced networking application to minimize the extra delay it induces in the bottleneck while implementing an end-to-end version of scavenger service. At least one such protocol has now been implemented by a major peer-to-peer application and deployed in the wild with favorable results. Another is a document that addresses community concerns about the use of multiple transport connections by peer-to-peer applications, both when these connections run to the same peer and to different peers. These two items appear to fall within the Transport area, but not within the charter of any existing working group. It is not obvious what WG's charter could be naturally extended to encompass these two items. The TANA BoF is held to explore the problem space, gauge the interest in the problems within the Transport area, and to see if the community and the area directors believe that it makes sense to form a TANA working group within the Transport area chartered to work on 1. standardizing end-to-end congestion control that enables advanced application to minimize the delay they introduce into the network and a protocol using it and 2. a document describing the current practice of peer-to-peer apps' use of multiple transport connections and recommendations in this space.1. Requirements notation "HIP Extensions for Object to Object Communications", Gyu Myoung Lee, Jun Kyun Choi, Taesoo Chung, 7-Jul-08, This document explains the concept of object to object communications and specifies naming and addressing issues for object identification. In order to use Host Identity Protocol (HIP) for object to object communications, this document provides the extended architecture of HIP according to mapping relationships between host and object(s). In addition, packet formats and considerations for HIP extensions concerning object are specified. "Customer MAC Address Flushing Mechanisms for Provider Backbone Bridging over VPLS", Ali Sajassi, Samer Salam, Luyuan Fang, Nabil Bitar, Dinesh Mohan, 7-Jul-08, The scalability of H-VPLS (either with MPLS or Ethernet access network) can be improved by incorporating Provider Backbone Bridge (PBB) functionality in VPLS access. PBB introduces the notion of Backbone MAC (B-MAC) addresses vs. Customer MAC (C-MAC) addresses, thereby leading to the requirement for having MAC address flushing mechanisms for each. This document discusses a C-MAC address flushing notification mechanism to be used in VPLS networks that employ PBB technology. "Provider Backbone Bridges in H-VPLS with MPLS Access", Ali Sajassi, Samer Salam, Nabil Bitar, Dinesh Mohan, 7-Jul-08, Provider Backbone Bridge (PBB) functionality, under standardization in IEEE 802.1ah, can be employed to enhance the scalability of H- VPLS with MPLS access. This document describes how PBB technology can be used in H-VPLS with MPLS access networks to improve the scalability of customer MAC addresses and number of service instances that can be supported. The document also describes the migration mechanisms and scenarios by which PBB functionality can be incorporated into H-VPLS with existing MPLS access. "Applicability of Access Node Control Mechanism to PON based Broadband Networks", Nabil Bitar, Sanjay Wadhwa, 7-Jul-08, The purpose of this document is to provide applicability of Access Node Control Mechanism, as described in [ANCP-FRAMEWORK], to PON based broadband access. The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements), is described in a multi-service reference architecture in order to perform QoS-related, service- related and Subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device- device communication. This allows for performing access link related operations within those network elements to meet performance objectives. "Mobility Considerations for 6LoWPAN", Geoffrey Mulligan, Carl Williams, David Huo, 8-Jul-08, There has been discussion recently within the 6LoWPAN community regarding mobile usage scenarios. Mobility considerations and analysis is required to ensure proper performance for the mobile usage cases. Also, mobility in 6LoWPAN sensor networks may present unique challenges to the 6LoWPAN architecture. Hence it is best to have mobility as a consideration upfront rather than an after thought in the development of 6LoWPAN milestones. This document provides a mobility perspective to the 6LoWPAN sensor network architecture. "AntiVirus Markup Language(AVML)", Antiy Labs, Antiy Labs, 11-Jul-08, This document describes the AntiVirus Markup Language(AVML). AVML is common standards language for storage, interaction and statistics of malicious software information. Malware information described by AVML More easily is dealt in distributed system. At the same time, people can read it . This document defines the AVML and explains the elements in AVML. "General Virus Process Language(GVPL)", Antiy Labs, Antiy Labs, 9-Jul-08, General Virus Process Language (GVPL) is lua scripting language expansion. It is designed to dispose of the virus which found in network terminal quickly. Because of the flexibility and simplicity of Lua script, GVPL is easy to achieve the goal which is rapid response to large-scale expansion of the virus. At the same time,it will reduce economic losses of users. "Dual-stack lite broadband deployments post IPv4 exhaustion", Alain Durand, 7-Jul-08, The common thinking for the last 10+ years has been that the transition to IPv6 will be based on the dual stack model and that most things would be converted this way before we ran out of IPv4. It has not happened. The IANA free pool of IPv4 addresses will be depleted soon, way before any significant IPv6 deployment will have occurred. This document revisits the dual-stack model and introduces the dual- stack lite technology aimed at better aligning the cost and the benefits of deploying IPv6. It will provide the necessary bridge between the two protocols, offering an evolution path of the Internet post IANA IPv4 depletion. "Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", Marianne Mohali, 11-Jul-08, Both History-Info and Diversion headers are able to transport diverting information in Session Initiation Protocol (SIP) signaling. This document proposes a way to map call forwarding information contained in a Diversion header into a History-Info header and vice versa. In addition, an interworking policy is proposed to manage the headers coexistence. Prior to existence of [RFC4244] describing the History-Info header, there was a draft introducing a header named Diversion for the transport of diversion information. Since the Diversion header is used in many existing networks implementations and it is not standardized for transport of diversion information, a mapping with the standardized History-Info header is needed. "DNS Encryption", Duane Groth, 14-Jul-08, This document requests IANA registration of a new DNS OpCode and ErrorCode type in facilitating encryption of DNS requests and replies and feed back to the client if plain text requests are not acceptable. Once this OpCode is seen the DNS server attempts to decrypt the request using its private OpenPGP key. Inside the encrypted packet is the AES key which the client expects to be used when the server encrypts a response. A server may advertise that it is capable of DNS encryption by returning OpenPGP fingerprints in TXT records using a similar format to Public Key Association (PKA). The full pubic keys are returned from DNS servers by using a CERT request against the host name(s) of the domain's NS records or via OpenPGP key servers. "Commercial Routing Requirements in Low Power and Lossy Networks", Jerry Martocci, Ted Humpal, Nicolas Riou, Jon Williamsson, 14-Jul-08, The ROLL Working Group was recently chartered by the IETF to define routing characteristics for low power embedded devices. ROLL would like to serve the Industrial, Commercial, Home and Urban markets. Pursuant to this effort, this document defines the functional and cost requirements for installing integrated facility management systems in commercial facilities. The routing requirements for commercial building applications are presented in this document. Commercial buildings have been fitted with pneumatic and subsequently electronic communication pathways connecting Martocci Expires January 14, 2009 [page 1] Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008 sensors to their controllers for over one hundred years. Recent economic and technical advances in wireless communication allows facilities to increasingly utilize a wireless solution in lieu of a wired solution; thereby reducing installation costs yet maintaining highly reliant communication. Wireless solutions will be adapted from their existing wired counterparts in many of the building applications including, but not limited to HVAC, lighting, security, fire, and elevator products. These devices will be developed to reduce installation costs; while increasing installation and retrofit flexibility. Sensing devices may be battery or mains powered. Actuators and area controllers will be mains powered. To meet the cost target, these devices must have a total installed cost below that of the traditional wired alternative; yet maintain reliability on par with wired devices. The total installed cost includes the infrastructure, product, installation, commissioning, labor and operational costs of the device over its 30 year lifespan. Except for special circumstances such as flexible installation (e.g. airports) or cosmetics (e.g. museums, there is nothing compelling about installing wireless solutions inside a building unless it can be accomplished below the cost of a wired installation. This document will define the requirements necessary for wireless technology to displace wired infrastructure and meet this objective. "Faster application handshakes with SYN/ACK payloads", Adam Langley, 5-Aug-08, This document advocates the usage of small, mostly constant payloads in the SYN+ACK frame of the 3-way TCP [RFC0793] handshake. We show how this can have immediate benefits for some protocols. Additionally, we describe a new TCP option that enables a wider range of protocols to gain from it. "User centric QoS policy management for heterogeneous Internet environment", Ilka Miloucheva, Irit Sterdiner Mayer, P.A. Aranda Guiterrez, Adam Flizikowski, Christophe Chassot, 18-Jul-08, This document presents a framework for user-centric Quality of Service (QoS) management in heterogeneous Internet environments (considering fixed, mobile and broadcast networks). The framework is based on dynamic business level QoS policy specification by different actors (such as users, operators and administrators), as well as hierarchical policy refinement and translation, supporting the automated configuration of QoS mechanisms at heterogeneous network and transport entities. The hierarchical policy approach involves abstractions and mapping of policies described at business, unified, operational and configuration level considering networks with different capabilities and QoS requirements of different actors. The policy specification is dependent on the Service Level Agreements (SLAs) of the particular actors. This allows controlled and restricted usage of the network resources by the actors according to the actor dependencies and corresponding SLA rules. The policy management framework includes components for dynamic actor-based QoS policy specification, policy consistency check and dependency analysis regarding SLAs, automated policy provisioning and configuration at heterogeneous transport and network entities, policy monitoring and performance assessment, as well as automated adaptation of QoS mechanisms at operational level. Policy enforcement combined with policy monitoring and performance assessment is considered, as well as automated adaptation of policy parameters (e.g. operational policies) based on policy performance analysis. Interactions of components for policy specification and automated provisioning are based on policy repository storing the unified (intermediate) policy representations describing policy parameters, conditions and actions. "Border Router Discovery Protocol (BRDP) based Address Autoconfiguration", Teco Boot, Arjen Holtzer, 18-Jul-08, Mobile Ad hoc Networks may be attached to a fixed infrastructure network, like the Internet. This document specifies a mechanism for Border Router discovery and utilization in such a subordinate, possibly multi-homed, MANET. It provides facilities for choosing the best Border Router and configuring IP addresses needed for communication between MANET nodes and nodes in the fixed infrastructure via the selected Border Router. "A CGA based Source Address Authorization and Authentication (CSA) Mechanism for First IPv6 Layer-3 Hop", Jun Bi, Jianping Wu, Guang Yao, 27-Jul-08, This document describes a method to authorize and authenticate the address of a node in an IPv6 network. Except for "Host Change", this method satisfies all the requirements in the Charter of SAVI. The modification on a host can be regarded as the extension of SEND and IPSec. "Specifying Derived Location in a PIDF-LO", James Winterbottom, Martin Thomson, 27-Jul-08, This document describes how specify that a location in a PIDF-LO has been derived or converted from a different location. The source location may reside in the same PIDF-LO or be a remote document referenced by a location URI and associated id fragement. "Advertisement of the best-external route to IBGP", Pedro Roque Marques, Rex Fernando, Enke Chen, Pradosh Mohapatra, 27-Jul-08, This document makes a case and provides the rules for a border router to advertise its best external route towards its IBGP peers when its overall best is a route received from an IBGP peer. The best external route may be different from the overall best route installed in the Loc-Rib. Advertising the best-external route (when different from the overall best route) into an IBGP helps in speeding up routing convergence, has positive effects in reducing inter-domain churn and in some limited scenarios could help avoid permanent IBGP route oscillation. The document also extends this mechanism to route reflectors and confederation border routers to advertise a best route that is external to the cluster/domain. "FTP Extension Registry", John Klensin, 27-Jul-08, Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. As the number of those extensions increases, it appears useful to establish an IANA registry to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry. "FTP Extension for Internationalized Text", John Klensin, 27-Jul-08, The original FTP protocol supported TYPE values for ASCII and EBCDIC text, plus binary ("IMAGE") transmission. As the Internet becomes more international, there is a growing requirement to be able to transmit textual data, encoded in Unicode, in a way that is independent of the coding and line representation forms of particular operating systems. This memo specifies a new FTP TYPE value for Unicode data. "Location and Discovery of Subsets of Resources", Lican Huang, 27-Jul-08, This file is a proposal for location and discovery of filter resources selected by search-conditions. The peers,which are virtually grouped, construct n-tuple overlay virtual hierarchical tree overlay network. With cached addresses of peers, the overload of traffic in tree structure can be avoided. The resources are classified into hierarchical domains, and registered into the peers which are located in the same domain virtual groups as the resources'. This proposal supports flexible queries by a SQL-like query statement. "Textual Representation of AS Numbers", George Michaelson, Geoff Huston, 28-Jul-08, A textual representation for Autonomous System (AS) numbers is defined using "asdot" notation. This textual representation is to be used by all documents, systems and user interfaces referring to AS numbers. "Textual Representation of AS Numbers", Geoff Huston, George Michaelson, 28-Jul-08, A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS Number. This textual representation is to be used by all documents, systems and user interfaces referring to AS numbers. "Neighbor Discovery and Autoconfiguration for Route-Over 6LoWPAN Networks", Jonathan Hui, 28-Jul-08, This document specifies a simple version of IPv6 Neighbor Discovery for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discover routers, discover network configuration parameters, and IPv6 prefixes for use with stateless address autoconfiguration and context-based 6LoWPAN compression for IPv6 headers. This document also specifies autoconfiguration mechanism for use in 6LoWPAN networks. "Capabilities Update Problem Statement", Tina Tsou, 28-Jul-08, This specification clarifies "Capabilities Update" in OPEN state defined in RFC 3588bis. Capabilities update in OPEN state can reuse commands CER/CEA commands for re-negotiation between Diameter peers when one of them changes its capabilities.It is a very important function in Diameter. However, RFC 3588 has defined a mechanism of containing capabilities list both in CER and CEA commands and the peer should update its local database whenever it receives CER/CEA. This makes the process complex and redundant when they are used in OPEN state. So this draft proposes a simpler solution based on CER/CEA commands to deal with this problem. "EDNS0 Support in Authority Servers on 27 July 2008", Shane Kerr, Joe Abley, 28-Jul-08, This memo documents the methodology and results of an experiment which tested the availability of the DNS Extension Mechanism (EDNS0) on a large set of authority-only nameservers. The experiment was conducted in the bar during the IETF 72 meeting on 27 July 2008. The results of this experiment suggest that EDNS0 deployment is extensive: it was found that 94.4% of non-defective authority-only servers are EDNS0-capable. "Incentives and Deployment Considerations for P2PI Solutions", Jari Arkko, 29-Jul-08, Several papers in the May 2008 P2PI workshop have argued that there is a need to build new protocol mechanisms to accommodate peer-to- peer traffic in networks in the most efficient way and with minimal impact to other traffic. This paper presents an analysis of such solutions from the point of view of the incentives of the different parties involved in peer-to-peer traffic. The paper concludes that it is essential to understand the incentives in order to have a deployable solution. "Requirements for handling abandoned calls and premature disconnects in emergency calls on the Internet", Brian Rosen, 29-Jul-08, The -phonebcp draft currently requires endpoints to disable sending a BYE on an emergency call. Insufficient justification and lack of attention to the entire problem has caused comment on that section of the document. This document attempts to define the problem and the requirements to controlling disconnect on emergency calls. "MSWS Method to Support Shared-Mesh Restoration for Wavelength Switched Optical Networks", Lin Guo, Yuefeng Ji, Hongxiang Wang, 29-Jul-08, This document proposes a method called Most Sharable Wavelength per Segment (MSWS) to support shared-mesh restoration for wavelength switched optical networks (WSON). The proposed method can perform efficient wavelength sharing in a distributed fashion. It uses the signaling extensions for WSON which is previously proposed in the document "Signaling Extensions for Wavelength Switched Optical Networks" (draft-bernstein-ccamp-wson-signaling-01) and no other protocol extensions of Generalized Multi-Protocol Label Switching (GMPLS) routing and signaling are needed. "HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signalling (HICCUPS)", Pekka Nikander, Gonzalo Camarillo, Jan Melen, 30-Jul-08, This memo defines how one can use HIP packet formats, and optionally the HIP base exchange, to securely convey arbitrary signalling messages over the Internet or various overlay networks. "Remote Triggered Black Hole filtering with uRPF", Warren Kumari, Danny McPherson, 26-Sep-08, Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial of service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. It also defines a standard BGP community for black hole prefixes to simplify associated semantics. "IESG Procedures for Handling of Independent and IRTF Stream Submissions", Harald Alvestrand, Russ Housley, 7-Oct-08, This document describes the procedures used by the IESG for handling documents submitted for RFC publication on the Independent and IRTF streams. This document updates procedures described in RFC 2026 and RFC 3710. "Dynamic Host Configuration Protocol Option for Softwires", David Hankins, 11-Aug-08, This document describes how Softwires configuration can be obtained via DHCPv6. "Application Extension Bundle description Language (AEBL)", Trevor Clarke, 31-Jul-08, This memo presents an RDF [refs.RDF] vocabulary for describing an application extension bundle [refs.aeb]. An application extension bundle, otherwise known as an add-on, extension, plug-in, suite, or package, is an encapsalation of all the data needed to add functionality to a plug-in based application. An integral piece of an application extension bundle is the metadata describing the bundle. The described RDF vocabulary contains required and optional metadata fields used by an application extension bundle to describe itself. "Application Extension Bundle (AEB)", Trevor Clarke, 31-Jul-08, This memo presents a file format for describing an application extension bundle. An application extension bundle, otherwise know as an add-on, extension, plug-in, suite, or package, is an encapsalation of all the data needed to add functionality to a plug-in based application. "Guidance on Interoperation and Implementation Reports", Lisa Dusseault, Robert Sparks, 31-Jul-08, Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. "Nest Route Optimization for NEMO (NERON)", Faqir Zarrar Yousaf, Christian Wietfeld, Alain Tigyo, 21-Aug-08, IETF has proposed MIPv6 based Network Mobility (NEMO) Basic Support protocol that handles the mobility management of IPv6 based mobile networks. However the NEMO protocol has severe performance limitations and does not specify the route optimization method for mobile networks and does not take into account the operational and functional complexities involving nested mobile networks. In this draft we present NEst Route Optimization for NEMO (NERON) protocol, a light weight, efficient and scalable approach that aims at enabling nodes behind nested mobile networks to use optimized communication paths with zero tunneling overhead and minimum end-to- end delay, irrespective of the depth of the nest, with minimum but manageable changes to the base MIPv6 and IPv6 Neighbor Discovery protocols and without introducing any new network entities. "The Expires Header in E-mail", Michael Welzl, Thomas Nolf, Jacob Palme, 4-Aug-08, This memo introduces a new email header called Expires. Using this header, the sender of an email can state that (s)he believes this message will be irrelevant after the indicated date/time. The receiving MUA can then automatically detect that a message has expired and facilitate handling of such emails for the user. "IPv6 Path MTU computation using routing protocol", Vijay Kumar Vasantha, 4-Aug-08, This document describes a mechanism for dynamically computing IPv6 PMTU and the modifications needed in IPv6 to support the solution. "ISIS: Path MTU calculation in ISIS", Vijay Kumar Vasantha, 4-Aug-08, This draft defines a method for calculating the PMTU for each IPv6 destinations using ISIS routing protocol. By doing so the overhead incurred in the existing path maximum transferable unit discovery mechanism is reduced and the same solution can be extended to other link state routing protocols as well. "SASL Mechanism for External Authentication using Channel Bindings: EXTERNAL-CHANNEL", Simon Josefsson, 5-Aug-08, This document describes a way to perform end-user authentication in the Simple Authentication and Security Layer (SASL) framework which re-use an external security layer (such as the Transport Layer Security (TLS) protocol) that may have already completed end-user authentication. In comparison with the existing EXTERNAL mechanism, this mechanism offers a way to cryptographically bind the authentication to the security layer via a channel binding. The EXTERNAL-CHANNEL mechanism alleviates the a priori assumptions made by the design of the EXTERNAL mechanism. See for more information. "MLD Extensions to Support the Mobile Multicast Group Management", Hong-Ke Zhang, Jian-feng Guan, Hua-chun Zhou, Zhi-wei Yan, 5-Aug-08, Mobile multicast is a research hotspot. Some mobile multicast schemes was proposed, but most of them depend on the traditional group membership management protocol and concern on the reconstruction of multicast delivery tree by various algorithms, and they little consider the mobile group membership management. So in this memo, we extend the MLD protocol to support the mobile multicast group management. The extension is compatible with the traditional MLD protocols, and it can also be applied to the IGMP protocol to manage the mobile multicast in IPv4. "Auto Issued X.509 Certificate Mechanism (AIXCM)", Thierry Moreau, 6-Aug-08, The Transport Layer Security (TLS) protocol does not support the use of client public key pairs without X.509 security certificates. This document circumvents this limitation: an end-entity has access to the public domain private key of a dummy (or "explicitly meaningless") Certification Authority (CA), and can thus freely issue an X.509 security certificate for interoperability purposes. Given these workaround requirement and solution approach, the document limits itself to the strict minimal set of standardization provisions. This supports the orderly cohabitation of auto issued certificates and normal TLS traffic relying on the full Public Key Infrastructure (PKI) model. "Problems observed with RSVP recovery signaling", Andrew Rhodes, Nic Neate, David McWalter, 6-Aug-08, Implementation experience with RSVP-TE recovery signaling has uncovered some problems. Associations between LSPs in different sessions are forbidden. Protecting LSPs cannot themselves be protected. Overlapping repairs cause loss of traffic. This draft provides details of these problems for the community to consider. "A DNS Resource Record for Additional Entropy", Jim Reid, 6-Aug-08, A scheme to defend against cache poisoning attacks against the Domain Name System (DNS) by predicting the ID and source port number of outgoing queries is described in this draft. It proposes a new resource record to provide a mechanism to introduce additional entropy into DNS queries. "Translator Friendly DNS Proxy", Masahito Endo, Hiroshi Miyata, 1-Oct-08, This document describes the DNS Proxy that is separated from NAT-PT [RFC2766]. NAT-PT was designed to work with DNS Application Level Gateway. However [RFC4966] pointed out DNS related issues, and [RFC2766] was changed to historical state. This document attempts to DNS Proxy specification, removing dependency on NAT-PT as well as resolving problems pointed in [RFC4966]. "DKIM Author Domain Signing Practices (ADSP) Security Issues", Douglas Otis, 30-Sep-08, The proposed [I-D.ietf-dkim-ssp] defines DNS records that advertise the extent to which a domain employs [RFC4871] to sign [RFC2822] messages, and defines how other hosts can access these advertisements. Its laudable goal is to allow domains control over the use of the From header field. When a message is not adequately signed, advertised assertions, referenced by a domain in the From header field, assist in resolving the message's intended disposition. Rather than dealing with keys that impose a restriction on the "on- behalf-of" identity as a separate security consideration to be handled independently from an assertion that a domain signs their messages, [I-D.ietf-dkim-ssp] instead employs a flawed two-stage signature validation process that works in conjunction with advertised practices. The two-stage approach will most likely occur after message acceptance, and impairs the range of authentication assertions permitted by a single signature. The limitations on authentication assertions inhibits tactics needed to deal with replay abuse. As currently structured, advertised practices not only assert whether a signature should be expected, they also constrain the "on-behalf-of" identity applied by signing agents that are not otherwise so restricted by [RFC4871]. By constraining the "on- behalf-of" identity for all signing agents, the draft neglects the predominate role of the domain as a point of trust, and incorrectly assumes the signature is limited to supporting assertions regarding the identity of the author. By limiting the DKIM signature's "on- behalf-of" value to being representative of only the message's author, the draft goes well beyond the working group's charter and appears to infringe on S/MIME's and OpenPGP's role. [I-D.ietf-dkim-ssp] impairs security in other ways as well, such as the only directly actionable practice is defined using a term likely to negatively impact the integrity of delivery status. Fortunately minor changes to the definition of a compliant signature can remedy the impairment created, where the critical security issues are best handled independent of any [I-D.ietf-dkim-ssp] assertion. "New Tunnel-Type Values", Abhishek Tiwari, 29-Aug-08, This document defines a set of values for the Tunnel-Type RADIUS Attribute. "Kerberos ticket extensions", Love Astrand, 14-Sep-08, The Kerberos protocol does not allow ticket extensions. This make it harder to deploy features like referrals and PKCROSS. Since the Kerberos protocol did not specified extensibility for the Ticket structure and the current implementations are aware of the contents of tickets, the extension protocol cannot simply extend the Ticket ASN.1 structure. Instead, the extension data needs to be hidden inside the ticket. This protocol defines two methods to add extend the tickets. The first method requires updated clients and is more in line with the future development of Kerberos. The second way does not require update client. To take advantage of this protocol the server (KDC or application server) need to update a well. The two methods are equivalent and there is a 1-1 mapping between them. "GSS-API: Delegate if approved by policy", Love Astrand, Sam Hartman, 23-Sep-08, Several GSS-API applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers as well as CIFs file servers. However, delegating the ability to act as a user to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). "ECC Support for SEND/CGA", Sean Shen, Michaela Vanderveen, 10-Oct-08, This draft proposes an upgrade to the SEND/CGA protocols to incorporate support for elliptic curve cryptography. "Approach to Digital Signature Systems Deployment", John Marchioni, Yair Itzhaki, 14-Aug-08, Most digital-signature system deployments require dedicated and solution-specific user-enrollment procedures and user-enrollment software[1], and mandate provisioning and distribution of physical or software-based signature-key tokens to end users. As deployed such approaches create a high burden in logistics, cost, and help-desk support. They also introduce training obstacles for users and systems administrators. This document describes the deployment architecture approach used by ARX to provide secure and efficient digital signature services based on its CoSign(r) solution. The security solution's deployment architecture is documented in the hope that other digital-signature and PKI deployment efforts will deliver comparable efficiencies. [1] This is also true for deployments of non-standard proprietary electronic signature solutions. "OpenPGP Attribute Extension", Duane Groth, 14-Aug-08, A RFC was accepted extending TLS usage to include OpenPGP keys (RFC 5081) as an alternative or in addition to X.509 certificates, however the author did not really standardise the way the information in OpenPGP keys was to be presented and this could be detrimental or fragment efforts to utilise OpenPGP keys in this manner. The author didn't touch on the issue generating confidence scores beyond potential use of Certificate Authorities. "Applicability of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) Headers", Julian Reschke, 15-Aug-08, By default, message header parameters in Hypertext Transfer Protocol (HTTP) messages can not carry characters outside the ISO-8859-1 character set. RFC 2231 defines an escaping mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies a profile of that encoding suitable for use in HTTP. "EDNS Option for performing a data PING", Bert Hubert, David Ulevitch, 17-Aug-08, For various reasons, it may be desireable to ask a remote nameserver to add certain data to the response to a query. This document describes an EDNS option that implements such behaviour. "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", Arnaud Ebalard, Sebastien Decugis, 18-Aug-08, This document describes the need for an interface between Mobile IPv6 and IPsec/IKE and show how the two protocols can interwork. An extension of the PF_KEY framework is proposed which allows smooth and solid operation of IKE in a Mobile IPv6 environment. This document is heavily based on a previous draft [MIGRATE] written by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. It simply reuses the MIGRATE mechanism defined in the expired document, removes a companion extension (SADB_X_EXT_PACKET) based on implementation feedback (complexity, limitations, ...) and fills the gap by very simple changes to MIGRATE mechanism. This results in a more simple and consistent mechanism, which also proved to be easier to implement. This document is expected to serve as a continuation of [MIGRATE] work. For that reason, the name of the extension has been kept. PF_KEY MIGRATE message serves as a carrier for updated address information for both the in-kernel IPsec structures (SP/SA) and those maintained by the key managers. This includes in-kernel SP/SA endpoints, key manager maintained equivalents and addresses used by IKE_SA (current and to be negotiated). The extension is helpful for assuring smooth internetworking between Mobile IPv6 and IPsec/IKE for the bootstrapping of mobile nodes and their movements. "Alert-Info header URNs for Session Initiation Protocol (SIP)", Denis Alexeitsev, 2-Sep-08, The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone (RBT) for caller, or ring tone (RT) for callee using the Alert-Info header. However, the reference addresses only the network resources with specific rendering properties. There is currently no support for predefined standard identifiers for ringback tones or semantic indications without tied rendering. To overcome this limitations and support new applications a family of the URNs is defined in this specification. "Ivip4 ETR Address Forwarding", Robin Whittle, 22-Aug-08, ETR Address Forwarding (EAF) is a novel method by which an IPv4 Core- Edge Separation solution to the Internet's routing scaling problem can tunnel packets from an ITR to an ETR. EAF involves using 31 bits of the IPv4 header for new purposes: bit 48, the More Fragments flag, the Fragment Offset field and the Header Checksum field. Consequently, packets in this format need to be handled by routers with modified functionality. EAF is an alternative to encapsulation (map-encap) or address translation (Six/One Router) and has advantages including: simpler ITRs and ETRs, direct support for conventional RFC 1191 PMTUD, no encapsulation overhead and full compatibility with IPsec AH and Traceroute. "Neighbor Discovery Suppression", Laurent Toutain, Guillaume Chelius, Yoongsoo Lee, Yongqiang DONG, 20-Aug-08, The 6LoWPAN IETF working group is developing protocols to allow IPv6 end-to-end communication with sensors networks. Low-power MAC protocols such as IEEE 802.15.4 impose a slightly reduced frame size. To enable IPv6 communication, 6LoWPAN proposes to use fragmentation and header compression techniques. This document proposes an extension to the 6LoWPAN proposal and defines a class of sensors that can be joined at the network level while ignoring their own global IPv6 address. This architecture centralizes the address management on the sensor network gateway (the PAN Coordinator) and allows the suppression of the Neighbor Discovery Protocol. Consequently, the insertion of sensors in such a network is faster and the traffic within the network, largely composed of broadcast messages generated by Neighbor Discovery Protocol, is reduced. We investigate the impact of this architecture on star and mesh topologies. "Rbridge Notes", Donald Eastlake 3rd, 20-Aug-08, This document provides additional informational material related to RBridges, which are devices that implement the TRILL protocol. It is a supplement to the RBridges base protocol specification and includes discussion of tradeoffs in some features and configurations of RBridges. In addition, it provides a sketch of a proof that, with reasonable assumptions, persistent loops do not occur in a TRILL campus. "Inter-Technology Handoff support in Mobile Node for Proxy Mobile IPv6", Hidetoshi Yokota, Sri Gundavelli, Kent Leung, 21-Aug-08, Proxy Mobile IPv6 supports a handoff between different access technologies, by which the assigned IP address is preserved regardless of the access technology type. From the perspective of the mobile node, this involves the change of the network interfaces, through which the IP address is assigned and the IP session is established. Some implementations, however, do not assume this interface switching in the middle of the session and it could cause a disconnection by the event of unavailability of the current interface; hence it is not guaranteed to be able to maintain the IP session simply by assigning the same IP address to the new interface. This document analyzes the handling of the network interfaces on the mobile node and presents several measures to avoid a disconnection due to the interface switching. "IP and ARP over Wiegand", Scott Guthery, 22-Aug-08, This document describes the transport of IP datagrams over the Security Industry Association standard [3] five-conductor cable called the Wiegand interface used for communication between card readers and control panels in physical access control systems. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Images in RFCs", Robert Braden, John Klensin, 25-Sep-08, Documents in the RFC series normally use only plain-text ASCII characters and a fixed-width font. However, there is sometimes a need to supplement the ASCII text with graphics or picture images. The historic solution to this requirement, allowing secondary PDF and Postscript files, is seldom used because it is awkward for authors and publisher. This memo sugests a more convenient scheme for attaching authoritative diagrams, illustrations, equations or other graphics to RFCs. "Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications", David Hankins, 22-Aug-08, The DHCPINFORM message within the DHCPv4 protocol has in operation diverged incompatibly from the previously defined standard, and some questions about DHCPv4 server behaviour remain unclear. "The Metalink Download Description Format", Anthony Bryan, 18-Sep-08, This document specifies Metalink Documents, an XML-based download description format. "Security Assessment of the Internet Protocol version 4", Fernando Gont, 31-Aug-08, This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). "Resolver side mitigations", Wouter Wijngaards, 25-Aug-08, Describes a set of mitigations that stop the known Kaminsky variations, for which only resolver side deployment is necessary. "EDNS EXPIRE OPTION", Mark Andrews, 25-Aug-08, Provide a method for slave DNS servers to honour the SOA EXPIRE field as if they were always transferring from the master, even when using other slaves to perform indirect transfers and refresh queries. "With-defaults capability for NETCONF", Andy Bierman, Balazs Lengyel, 26-Aug-08, The NETCONF protocol defines ways to read configuration data from a NETCONF agent. Part of this data is not set by the NETCONF manager, but rather set to a default value by the NETCONF agent. In many situations the NETCONF manager has a priori knowledge about this data, so the NETCONF agent does not need to send it to the manager. In other situations the NETCONF manger will need this data as part of the NETCONF rpc reply messages. This document defines a capability- based extension to the NETCONF protocol that allows the NETCONF manager to control whether default values are part of NETCONF rpc reply messages. "Media Format Choices for RFCs", Dave Crocker, 27-Aug-08, Documents in the RFC series normally use only plain-text ASCII characters and a fixed-width font. However, there is sometimes a need to supplement the ASCII text with graphics or picture images. The historic solution to this requirement, allowing secondary PDF and Postscript files, is seldom used because it is awkward for authors and publisher. This memo suggests a more convenient scheme for attaching authoritative diagrams, illustrations, or other graphics to RFCs. It further proposes conventions for additional input and display formats, to improve readability. This proposal is based on draft-rfc-image-files-00, by Braden and Klensin, and revises it as little as possible, while expanding the goals of the effort. "Transport Layer Security (TLS) Authorization Using KeyNote", Angelos Keromytis, 1-Oct-08, This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to [AUTHZ]. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged during the supplemental data handshake message. "Spam reduction using messageid.", Mark Turner, 27-Sep-08, This draft suggests a technique of spam reduction by extending the SMTP service to include a 'Did You Send' query protocol. "An Architecture for Network Management", Philip Shafer, 4-Sep-08, NETCONF and YANG are pieces of an ambitious plan to improve network management. NETCONF gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content trafficked via NETCONF, both data and operations. Using both technologies, the standards modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network services providers. An architecture is described which is friendly to both devices and applications, to vendors and standards bodies, to young and to old, to red states and to blue states. It's a startling vision, coming to networks near you starting August, 2009. "Multicast Routing in Proxy Mobile IPv6", Hong-Ke Zhang, Jian-feng Guan, Hua-chun Zhou, ying zhu, 4-Sep-08, With the development of various mobile technologies, mobile multicast becomes a research hotspot. Several mobile multicast schemes were proposed, but most of them are based on the Mobile IPv6 and its alternatives. Recently, the Proxy Mobile IPv6 (PMIPv6) was proposed to provide the mobility support for mobile node without mobility function. However, the PMIPv6 mainly concerns on the unicast transmission support, and little considers the multicast routing. So, in this memo, we propose two mobile multicast mechanisms, the MAG- based method and LMA-based method to support the multicast routing in PMIPv6. "Never Ending Network Addresses: IPv4 Multiplexing trought IPv6", Alessandro Spinella, 5-Sep-08, While the wide use of IPv4 "private" addresses [RFC1918] lead to a great flexibilty degree of uninterconnected networks and use of IPv6 offer a huge address space; no "nice" mechanism exist to hide overlap of existing IPv4 "private" networks if and when the sum of used address spaces is greater than the IPv4 "private" address space. This document specifies how to walk around the matter without any coordination, renumbering or IPv6 adoption by overlapping networks owners. "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", Adrian Farrel, 12-Sep-08, Several protocols have been specified using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF. There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation. Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work. This document provides a formal definition of the variant of BNF that has been used (that we call Reduced BNF), and makes it available for use by new protocols. "Resolver side mitigations", George Barwood, 12-Oct-08, Describes mitigations against spoofing attacks on DNS, including: (1) Repeating the query, including techniques for handling non-deterministic responses. (2) Prepending a random nonce to the question where a referral is probable. (3) Estimating the entropy available, taking into account (a) Observed packets with incorrect IDs. (b) Records where the owner name does not match the question. (c) The previous content of the cache. "RTP Payload Format for Portable Network Graphics (PNG) image", Omer Boyaci, Henning Schulzrinne, 8-Sep-08, This document describes how to carry Portable Network Graphics (PNG) images in RTP packets. "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", Vishwas Manral, 8-Sep-08, This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. This document updates RFC3811 and fixes the . "Encapsulation Methods for Transport of InfiniBand over MPLS Networks", Suresh Shelvapille, Vikas Puri, 8-Sep-08, An InfiniBand(IB) pseudowire (PW) is used to carry InfiniBand frames over an MPLS network. This enables service providers to offer "emulated" InfiniBand services over existing MPLS networks. This document specifies the encapsulation of InfiniBand PDUs within a pseudowire. It also specifies how islands of IB fabrics can be connected via PWs to form a single IB subnet. "In-band signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", IJsbrand Wijnands, Toerless Eckert, Nicolai Leymann, Maria Napierala, 8-Sep-08, When an IP multicast tree needs to pass through an MPLS domain, it is advantageous to map the tree to a Point-to-Multipoint or Multipoint- to-Multipoint Label Switched Path. This document specifies a way to provide a one-one mapping between IP multicast trees and Label Switched Paths. The IP multicast control messages are translated into MPLS control messages when they enter the MPLS domain, and are translated back into IP multicast control messages at the far end of the MPLS domain. The IP multicast control information is coded into the MPLS control information in such a way as to ensure that a single Multipoint Label Switched Path gets set up for each IP multicast tree. "Link Connectivity and Common Constraint Information Extension to GMPLS for WDM Switched Optical Networks", Zhihong Kang, Zhenyu Wang, Feng Gao, 9-Sep-08, This document provides the mechanism of link connectivity verification and the constraint information extension to GMPLS IGP or Conveyed to a path computation element (PCE) for static light path computation and selection in WDM network. "Commercial Routing Requirements in Low Power and Lossy Networks", Jerry Martocci, Nicolas Riou, Pieter Mil, Wouter Vermeylen, 3-Sep-08, The ROLL Working Group was recently chartered by the IETF to define routing characteristics for low power embedded devices. ROLL would like to serve the Industrial, Commercial (Building), Home and Urban markets. Pursuant to this effort, this document defines the functional requirements for installing integrated facility management systems in commercial facilities. The body of this document defines the routing requirements for commercial building application. Other commercial building requirements such as cost and installation requirements have been included in Appendix A for reference. "AS Number Reservation for Documentation Use", Geoff Huston, 10-Sep-08, To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of Autonomous System numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation. "A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information", Samir Saklikar, Subir Saha, Ranjit Avasarala, 10-Sep-08, This draft defines a Session Initiation Protocol (SIP) Event Notification Framework-based mechanism for notifying Users about diversions (re-directions or forwarding) of their incoming communication sessions. A new event package is proposed for allowing users to subscribe for and receive such notifications. Users have further capability to define filters controlling the selection, rate and content of such notifications. The applicability of this event package includes 3GPP IMS. "Terminology in Low power And Lossy Networks", JP Vasseur, 30-Sep-08, The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. "Suite B Cryptographic Suites for Secure Shell", Kevin Igoe, 11-Sep-08, This document describes the basic architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol. Suite B secure shell makes use of elliptic curve Diffie-Hellmann (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the Advanced Encryption Standard running in Galois Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), and X.509 certificates. "SOS Uniform Resource Identifier (URI) parameter for marking of Session Initiation Protocol (SIP) requests related to emergency services", Milan Patel, 12-Sep-08, This memo describes requirements and protocol conventions for a new SIP (Session Initiation Protocol) URI parameter intended for marking SIP requests and responses related to emergency services. This proposal addresses issues that exist in the current 3rd Generation Partnership Project IP Multimedia Subsystem (IMS) Emergency services solution, but is not precluded from being used by other SIP-based emergency services solutions. It is not intended as a replacement for the service URN. "Delay-Tolerant Networking Metadata Extension Block", Susan Symington, 15-Sep-08, This document defines an extension block that may be used with the Bundle Protocol [2] within the context of a Delay-Tolerant Network architecture [4]. This Metadata Extension Block is designed to be used to carry metadata that forwarding nodes can use to make routing and other decisions regarding the bundle. This block is defined to enable the actual metadata that is inserted into the block to have any content and format, providing the format has been documented as a metadata ontology. Specific metadata ontologies may be defined in additional documents. "IVI Update to SIIT and NAT-PT", Xing Li, Congxiao Bao, Fred Baker, Kevin Yin, 16-Sep-08, This note proposes an address and service architecture designed to facilitate transition from an IPv4 Internet to an IPv6 Internet. This service contains three parts: A DNS Application Layer Gateway, a stateful Network Address Translator that enables IPv6 clients to initiate connections to IPv4 servers and peers, and a stateless Network Address Translator that enables IPv4 and IPv6 systems to interoperate freely. It is couched as an update to RFCs 2765 and 2766. This is because the stateless service is essentially the SIIT with a different address format, and because the DNS Application Layer Gateway and the stateful translator have significant similarities to NAT-PT. There are, however, important differences from NAT-PT, responsive to the issues raised in RFC 4966. "BU/BA Based Prefix Delegation Support for Mobile Networks", Behcet Sarikaya, Frank Xia, 15-Sep-08, This document defines prefix delegation support for a mobile network. Mobile Router dynamically requests its Mobile Network Prefixes from its Home Agents using Binding Update both at the home link and at the visited links. Home agents get the prefixes delegated using DHCPv6 Prefix Delegation and reply to the Mobile Router with Binding Acknowledgement. "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", James Randall, 15-Sep-08, This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This is an update of 3447. Certain errors were also corrected for this update and are identified in the text. "A Comparison of Proposals to Replace NAT-PT", Dan Wing, David Ward, Alain Durand, 29-Sep-08, As we approach IPv4 address depletion, the IETF must provide for IPv4 and IPv6 coexistence: a way for ISPs and enterprises to reduce public IPv4 address consumption and a way for hosts to migrate to IPv6 connectivity -- while providing reasonable access for those IPv6 hosts to access the IPv4 Internet. This draft compares eight proposals for IPv6 and IPv4 coexistence. "Decrypted Content Attachment Flag for Internet Message Access Protocol (IMAP)", Dan Newman, Ned Freed, 16-Sep-08, This document promulgates an Internet Message Access Protocol (IMAP) flag keyword which Mail User Agents (MUAs) may use to indicate that the decrypted content of an encrypted message contains one or more attachments. This document intentionally leaves undefined the definition of an "attachment" and is neutral as regards the message encryption system. This document also defines an IANA registry for IMAP flag keyword conventions. "Multicast Support Requirements for Proxy Mobile IPv6", Hui Deng, Thomas Schmidt, Pierrick Seite, Peng Yang, 16-Sep-08, This document summarizes requirements for multicast listener support in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to PMIPv6, multicast mobility management requirements do not request any active participation of the mobile node. "IPv6 Connectivity Check and Redirection by HTTP Servers", Eric Vyncke, 17-Sep-08, Rather than forcing the client to decide whether IPv4 or IPv6 is more convenient to reach a web server; this document proposes to let the web server check whether there is IPv6 connectivity to the client; then the web server can do a HTTP redirect to the force the client to use IPv6. This is done easily by a script within the server HTML pages and does not require any change in the client applications or configuration. The client still can control whether he/she wants to enabled IPv6. This draft could be discussed on the Applications Discuss mailing list, https://www.ietf.org/mailman/listinfo/apps-discuss. "IETF Streaming Media, Current Status", Joel Jaeggli, 17-Sep-08, This document describes the operation of the audio streaming service provided for the IETF from IETF 62 up to the most recent (IETF 72) meeting. Efforts associated with meetings prior to IETF 62 back to IETF 49 as well as a proposal for the current effort were detailed in the now expired draft draft-jaeggli-ietftv-ng-01.txt. The purpose of this document is to inform future efforts to deliver streaming media services for remote or local participants of the level of service and the technology that was employed. "Signaling 3 PCN states with baseline encoding", Ruediger Geib, 19-Sep-08, Layer 2 transport services like MPLS offer only 2 states to encode ECN state, if DiffServ based Class of Service is operated. Still, a mechanism by which PCN egress nodes can differentiate between the normal behaviour state, admission stop state control state and flow termination state, by using PCN marking of packets is desirable. This document describes how threshold and excess marking can be combined with PCN baseline encoding. A minimalistic approach like the one described in the following has some obvious shortcomings. These shortcomings are also presented and discussed. Currently, the aim of this document is to trigger experimentation feasability studies. Standardisation will be pursued in the future based on the results of the studies. "IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios", Jari Arkko, Mark Townsley, 19-Sep-08, When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. "RTP Payload Format for MPEG-4 Audio/Visual Streams", Yoshihiro Kikuchi, Yoshinori Matsui, Toshiyuki Nomura, Shigeru Fukunaga, Hideaki Kimata, Malte Schmidt, Frans Bont, Intellectual Property, 19-Sep-08, This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Multipurpose Internet Mail Extensions (MIME) type registrations and the use of Session Description Protocol (SDP). Comments are solicited and should be addressed to the working group's mailing list at avt@ietf.org and/or the author(s). "Using POST to add Members to Web Distributed Authoring and Versioning (WebDAV) Collections", Julian Reschke, 2-Oct-08, The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST". This has lead to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. As a matter of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols such as the Calendar Extensions to WebDAV (CalDAV) frequently require clients to pick a unique URL, although the server could easily perform that task. This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. "Comparison of OSPF-MDR and OSPF-OR", Richard Ogier, Intellectual Property, 22-Sep-08, This document presents a comparison of two proposed MANET extensions of OSPF: OSPF-MDR and OSPF-OR. It includes a simulation comparison and a qualitative comparison, which discusses the different design choices and how they can affect performance and scalability. "Comparison of OSPF-MDR and OSPF-MPR", Richard Ogier, Intellectual Property, 22-Sep-08, This document presents a comparison of two proposed MANET extensions of OSPF: OSPF-MDR and OSPF-MPR. It includes a qualitative comparison, which discusses the different design choices and how they can affect performance and scalability, and a simulation comparison. "RSVP-TE Recovery Signaling Fixes", Andrew Rhodes, Nic Neate, David McWalter, 24-Sep-08, This document updates the ASSOCIATION object used in RSVP-TE signaling of End-to-End and Segment Recovery. This document solves problems with existing Segment Recovery procedures, and also makes possible recovery paths that cross addressing domain boundaries. " Dynamic Host Configuration Protocol (DHCP) Options for Port Restricted IP Address Assignment", Gabor Bajko, Teemu Savolainen, 24-Sep-08, This document defines two Dynamic Host Configuration Protocol for IPv4 [RFC2131] options that allow servers to assign port restricted IPv4 addresses to clients. Port restriction may be necessary in cases when one public IPv4 address is assigned to multiple clients because of scarcity of the available IPv4 addresses. "Alternative Approaches to Traffic Engineering Database Creation and Maintenance for Path Computation Elements", Greg Bernstein, Young Lee, Dan Li, 26-Sep-08, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this TED has been obtained from a link state routing protocol supporting traffic engineering extensions. This document discusses possible alternatives and enhancements to such an approach and their potential impacts on network nodes, routing protocols, and PCEs. "Fast Connectivity Restoration Using BGP Add-path", Pradosh Mohapatra, Rex Fernando, Clarence Filsfils, Robert Raszuk, 27-Sep-08, A BGP route defines an association of an address prefix with an "exit point" from the current Autonomous System (AS). If the exit point becomes unreachable due to a failure, the route becomes invalid. This usually triggers an exchange of BGP control messages after which a new BGP route for the given prefix is installed. However, connectivity can be restored more quickly if the router maintains precomputed BGP backup routes. It can then switch to a backup route immediately upon learning that an exit point is unreachable, without needing to wait for the BGP control messages exchange. This document specifies the procedures to be used by BGP to maintain and distribute the precomputed backup routes. Maintaining these additional routes is also useful in promoting load balancing, performing maintenance without causing traffic loss, and in reducing churn in the BGP control plane. "IPv4-IPv6 Coexistence Scenarios based on Stateless Address Mapping", Remi Despres, 28-Sep-08, As each global IPv4 address will be shared among more and more customers, and as more and more NATs will be deployed in ISP infrastructures, the lack of end-to-end transparency and the limited scalability of some NATs are likely to cause increasing difficulties to customers and to ISPs. This document introduces IPv4-IPv6 coexistence scenarios where IPv4 addresses are shared with good scalability and, in favorable configurations, with full IPv4 end-to- end transparency. For this, the key tool is the Stateless Address Mapping (SAM) of draft-despres-SAM-00, with in particular its extended IPv4 addressing (IPv4E) in which port prefixes are used as IPv4 address extensions. For each considered scenario, Static Address Mappers (SAMs) are deployed at scenario specific places. "OAuth: HTTP Authorization Delegation Protocol", Eran Hammer-Lahav, Blaine Cook, 29-Sep-08, This document specifies OAuth, an HTTP authorization delegation protocol for accessing protected resources. "Dual-stack lite broadband deployments post IPv4 exhaustion", Alain Durand, Ralph Droms, Brian Haberman, James Woodyatt, 29-Sep-08, The common thinking for more than 10 years has been that the transition to IPv6 will be based on the dual stack model and that most things would be converted this way before we ran out of IPv4. It has not happened. The IANA free pool of IPv4 addresses will be depleted soon, well before any significant IPv6 deployment will have occurred. This document revisits the dual-stack model and introduces the dual- stack lite technology aimed at better aligning the costs and benefits of deploying IPv6. Dual-stack lite will provide the necessary bridge between the two protocols, offering an evolution path of the Internet post IANA IPv4 depletion. "A Profile for AS Adjacency Attestation Objects", Geoff Huston, George Michaelson, 29-Sep-08, This document defines a standard profile for AS Adjacency Attestation Objects (AAOs). An AAO is a digitally signed object that provides a means of verifying that an AS has made an attestation that it has a inter-domain routing adjacency with one or more other AS's, with the associated inference that this AS may announce or receive routes with these adjacent AS's. "Stateless Address Mapping with A+P Extended IPv4 addressing (SAM)", Remi Despres, 29-Sep-08, Stateless Local Address Mapping (SAM) is a generic tool for global- address packets to traverse transit domains where routing is performed in different address spaces. To share IPv4 global addresses among several CPEs and/or hosts, port prefixes can be used as extensions of IPv4 global addresses. In this space (IPv4E), a node having an n-bits IPv4E prefix with n>32 may only use or delegate ports having its port prefix of length /32-n. Static Address Mappers can be placed in CPEs, in hosts, and/or in ISP Internet gateways. Applications include various IPv6 in IPv4 and IPv4E in IPv6 encapsulations. "Comprehensive DNS Resolver Defenses Against Cache Poisoning", Nicholas Weaver, 30-Sep-08, DNS resolvers are vulnerable to many attacks on their network communication, ranging from blind attacks to full men-in-the-middle. Although a full man-in-the-middle can only be countered with cryptography, there are many layers of defenses which apply to less powerful attackers. Of particular interest are defenses which only require changing the DNS resolvers, not the authoritative servers or the DNS protocols. This document begins with a taxonomy of attacker capabilities and desires, and then discusses defenses against classes of attackers, including detecting non-disruptive attacks, entropy budgeting, detecting entropy stripping, semantics of duplication, and cache policies to eliminate "race-until-win" conditions. Proposed defenses were evaluated with traces of network behavior. "Comprehensive DNS Resolver Defenses Against Cache Poisoning", Nicholas Weaver, 30-Sep-08, DNS resolvers are vulnerable to many attacks on their network communication, ranging from blind attacks to full men-in-the-middle. Although a full man-in-the-middle can only be countered with cryptography, there are many layers of defenses which apply to less powerful attackers. Of particular interest are defenses which only require changing the DNS resolvers, not the authoritative servers or the DNS protocols. This document begins with a taxonomy of attacker capabilities and desires, and then discusses defenses against classes of attackers, including detecting non-disruptive attacks, entropy budgeting, detecting entropy stripping, semantics of duplication, and cache policies to eliminate "race-until-win" conditions. Proposed defenses were evaluated with traces of network behavior. "Approach to Digital Signature Systems Deployment", John Marchioni, Yair Itzhaki, 30-Sep-08, Conventional deployments store keys on PC hard disks, application- server hard disks, or in tokens, and also introduce complications for user enrollment and management. User and administrator frustration with the conventional approach has cramped development of a market for PKI. As a result, PKI has not reached its utilization potential and is far from becoming ubiquitous. This document describes architecture for deployment of secure and efficient digital signature capabilities based on a centralized key- management approach and emphasizes the importance of not disrupting existing identity and authentication management and application infrastructure. An alternative architecture is documented here so that PKI deployments will lower their associated administrative burdens and deliver improved scalability. "MLD Source Address Selection for Mobile Multicast", Hong-Ke Zhang, Jian-feng Guan, Hua-chun Zhou, Zhi-wei Yan, 30-Sep-08, With the development of wireless and mobile technologies, mobile multicast becomes a research hotspot. However, the current multicast routing protocols can not provide the mobile multicast services. To support the mobile multicast, the related multicast specifications need to be extended. In this memo, we focus on the group membership management protocol and define the new source address selection policy for mobile multicast. "The Extension in NetLMM to Carry Network Condition Information", Hong-Ke Zhang, Hua-chun Zhou, Zhi-wei Yan, Jian-feng Guan, 30-Sep-08, The NetLMM WG is specifying Proxy Mobile IPv6 for network-based localized mobility management (NetLMM), taking basic support for registration, de-registration and handover into account in the first protocol release. When a mobile node connects to the access networks through a sole interface or multiple interfaces, the condition of the access networks should be considered to improve the performance of the ongoing applications. According to the normal operation, Local Mobility Anchor (LMA) can not get enough information to do the necessary scheduling with Mobile Access Gateway (MAG) and Mobile Node (MN), such as flow distribution. This document defines a PMIPv6 extension that carries network condition in the form of simple class indication which is calculated and sent from MAG to LMA in the Access Technology Type option. "Router Advertisement Extension to Recognize Access Location for Mobile Router", Hong-Ke Zhang, Zhi-wei Yan, Hua-chun Zhou, Jian-feng Guan, 30-Sep-08, The Router Advertisement message in IPv6 Neighbor Discovery Protocol [2] contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines a flag to the Router Advertisement message that extends the available number of flag bits available. The extended flag defined in this document is mainly used by Mobile Router to identify its location. "Identity Handling at a Session Initiation Protocol (SIP) User Agent", John Elwell, 1-Oct-08, Session Initiation Protocol (SIP) User Agents (UA) receive identifiers for the caller and callee during call establishment. These identifiers can come in a variety of forms, can be delivered by a variety of means, and may or may not be accompanied by evidence of authenticity. Furthermore, if media are secured (e.g., using the Secure Real-Time Protocol, SRTP), the security properties of the media will depend on binding the media to a received authenticated identifier. This document examines the various identification information a UA can receive during call establishment and how a user agent can use this information to present a caller or callee identifier to the user and indicate to the user the security properties of the call, as well as how the user agent might use this information for other purposes, such as authorizing acceptance of a call. This work is being discussed on the sip@ietf.org mailing list. "IKEv2 Session Resumption", Yaron Sheffer, Hannes Tschofenig, Lakshminath Dondeti, Vidya Narayanan, 1-Oct-08, The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. To re-establish security associations (SA) upon a failure recovery condition is time consuming, especially when an IPsec peer, such as a VPN gateway, needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In order to avoid the need to re-run the key exchange protocol from scratch it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach uses a ticket to store state information that is later made available to the IKEv2 responder for re-authentication. Restoring state information by utilizing a ticket, although the format is not specified in this document, is one possible way. "RFC Editor Model", Olaf Kolkman, 2-Oct-08, The RFC Editor performs a number of functions that may be performed by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Editor, the Independent Submission Editor, the RFC Production, and the RFC Publisher. The model intends to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality, maintaining timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. "Clearance Sponsor Attribute", Sean Turner, 3-Oct-08, This document defines the clearance sponsor attribute. This attribute may be carried in a public key certificate in the Subject Directory Attributes extension, in an attribute certificate in the attribute field, in a directory as an attribute, or in protocols that support attributes. "Device Owner Attribute", Sean Turner, 3-Oct-08, This document defines the deviceOwner attribute. This attribute may be carried in a public key certificate in the Subject Directory Attributes extension, in an attribute certificate in the attribute field, in a directory as an attribute, or in protocols that support attributes. "Threat Model for Networks Employing AAA Proxies", Katrin Hoeper, 3-Oct-08, his memo defines a threat model for access networks with AAA proxies. Use cases of current and future applications in which AAA proxies are employed are described and it is discussed how proxies could launch attacks in the defined use cases. The risk associated with these attacks in each use case is analyzed. As a result, this draft can serve as a guideline for risk assessments by providers, implementers and protocol designers of systems with proxies. "IANA Considerations for IAX: Inter-Asterisk eXchange Version 2", Ed Guy, 5-Oct-08, This document establishes the IANA registries for IAX, the Inter- Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. "RPKI Repository Retrieval Mechanism", Terry Manderson, George Michaelson, 5-Oct-08, This document proposes a mechanism for a relying party to synchronise a local cache of the RPKI repository using a HTTPS retrieval mechanism. "A UDP/IP Adaptation of the ZigBee Application Protocol", Gilman Tolle, 8-Oct-08, This document describes a UDP/IP adaptation of the IEEE 802.15.4- based ZigBee Application Protocol that enables IP hosts to communicate using the application profiles and data models described by that protocol, over a wide range of links. This modified version of the ZigBee Application Protocol is named CAP (Compact Application Protocol), and it is intended to provide a complete stack of application profiles, data exchange, binding operations, security protocols, and discovery to IP-networked hosts and embedded devices. The protocol's domain of applicability includes IEEE 802.15.4-based 6LoWPAN devices, but also those on conventional wired and wireless links and emerging powerline communication networks. "Revised Default Values for the BGP 'Minimum Route Advertisement Interval'", Paul Jakma, 9-Oct-08, This document briefly examines what is known about the effects of the BGP MRAI timer, particularly on convergence. It highlights published work which suggests the MRAI interval as deployed has an adverse effect on the convergence time of BGP. It then recommends revised, lower default values for the MRAI timer, thought to be more suited to today's Internet environment. "LMA Discovery for Proxy Mobile IPv6", Jouni Korhonen, Vijay Devarapalli, 10-Oct-08, Large Proxy Mobile IPv6 deployments would benefit from a functionality, where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway. This specification describes a number of possible dynamic Local Mobility Anchor discovery solutions. "IMAP Annotation for Indicating Message Authentication Status", Murray Kucherawy, 10-Oct-08, This memo defines an application of the IMAP (Internet Message Access Protocol) Annotations facility whereby a server can store and retrieve meta-data about a message relating to message authentication tests performed on the message and the corresponding results. 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, 30-Sep-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, 14-Jul-08, This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" framework. "Applicability Statement of NSIS Protocols in Mobile Environments", Takako Sanda, Xiaoming Fu, Seong-Ho Jeong, Jukka Manner, Hannes Tschofenig, 14-Jul-08, Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocol suite, and how the protocols operate in different scenarios, with mobility management protocols. "RMD-QOSM - The Resource Management in Diffserv QOS Model", Attila Bader, 7-Jul-08, This document describes an NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and pre-emption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. The RMD Ingress edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the edge nodes. Network Time Protocol (ntp) --------------------------- "Network Time Protocol Version 4 Protocol And Algorithms Specification", Jack Burbank, 5-Sep-08, The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP Version 4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3) described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol Version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms which extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. "Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)", Heiko Gerstung, Chris Elliott, 28-Aug-08, The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations and other networked equipment. As time synchronization is more and more a mission critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to setup a monitoring system that is platform- and vendor-independant. This Internet draft provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP Version 4 standardization effort. "Network Time Protocol Version 4 Autokey Specification", Brian Haberman, David Mills, 18-Aug-08, This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPSEC schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, PKI schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions. This memo includes the Autokey requirements analysis, design principles and protocol specification. A detailed description of the protocol states, events and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested and documented in the NTP Version 4 (NTPv4) software distribution for Unix, Windows and VMS at http://www.ntp.org. "Network Time Protocol (NTP) Server Option for DHCPv6", Richard Gayraud, Benoit Lourdelet, 11-Jul-08, The NTP Server Option for DHCPv6 provides NTP (Network Time Protocol version 4) configuration information to DHCPv6 hosts. An Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------------- "The Camellia Cipher in OpenPGP", David Shaw, 25-Apr-08, This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. Operations and Management Area Working Group (opsawg) ----------------------------------------------------- "Guidelines for Considering Operations and Management of New Protocols", David Harrington, 14-Jul-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-Aug-08, This memo (when approved as a standards-track RFC) defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in Extensible Markup Language (XML) Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. "Alarms in SYSLOG", Sharon Chisholm, Rainer Gerhards, 19-Jun-08, This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Security Best Practices Efforts and Documents", Chris Lonvick, David Spak, 6-Jun-08, This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). "Recommendations for filtering ICMP messages", Fernando Gont, Guillermo Gont, 31-Aug-08, This document document provides advice on the filtering of ICMPv4 and ICMPv6 messages. Additionaly, it discusses the operational and interoperability implications of such filtering. Open Shortest Path First IGP (ospf) ----------------------------------- "Management Information Base for OSPFv3", Dan Joyal, Vishwas Manral, 21-Sep-07, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). Please send comments to ospf@ietf.org. "OSPF Link-local Signaling", Alex Zinin, 22-Apr-08, OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well- defined fixed format. The format is not flexible enough to enable new features which need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. "OSPF MPR Extension for Ad Hoc Networks", Emmanuel Baccelli, Philippe Jacquet, Dang-Quan Nguyen, Thomas Clausen, 1-Oct-08, This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and denoted the "OSPFv3 MANET interface type". "Extensions to OSPF to Support Mobile Ad Hoc Networking", Madhavi Chandra, Abhay Roy, 21-Sep-08, This document describes extensions to OSPF to support mobile ad hoc networking. Specifically, the document specifies a mechanism for link-local signaling, a OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. Chandra, Roy et al. Expires March 2009 [page 1] Internet-Draft Extensions to OSPF to Support MANETs September 2008 "MANET Extension of OSPF using CDS Flooding", Richard Ogier, Phil Spagnolo, Intellectual Property, 10-Jun-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 link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. "Dynamic Hostname Exchange Mechanism for OSPF", Subbaiah Venkata, Sanjay Harwani, Carlos Pignataro, Danny McPherson, 15-Apr-08, Currently, there does not exist a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames just like for routers running IS-IS. This document defines a new OSPF Router Information (RI) TLV which allows the OSPF routers to flood their hostname-to-Router ID mapping information across the OSPF network. This mechanism is applicable to both OSPFv2 and OSPFv3. Peer-to-Peer Session Initiation Protocol (p2psip) ------------------------------------------------- "Concepts and Terminology for Peer to Peer SIP", David Bryan, Philip Matthews, Eunsoo Shim, Dean Willis, Spencer Dawkins, 7-Jul-08, This document defines concepts and terminology for use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related open problems being addressed by the P2PSIP working group. As this document matures, it is expected to define the general framework for P2PSIP. "REsource LOcation And Discovery (RELOAD)", Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, 14-Jul-08, This document defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes which do not need to route traffic or store data for others. Protocol for carrying Authentication for Network Access (pana) -------------------------------------------------------------- "PANA Enabling IPsec based Access Control", Mohan Parthasarathy, 14-Jul-05, PANA (Protocol for carrying Authentication for Network Access) is a protocol for authenticating clients to the access network using IP based protocols. The PANA protocol authenticates the client and also establishes a PANA security association between the PANA client and PANA authentication agent at the end of a successful authentication. This document discusses the details for establishing an IPsec security association using the PANA security association for enabling IPsec based access control. Path Computation Element (pce) ------------------------------ "Path Computation Element (PCE) Communication Protocol (PCEP)", Arthi Ayyangar, Adrian Farrel, Eiji Oki, Alia Atlas, Andrew Dolganow, Yuichi Ikejiri, Kenji Kumaki, JP Vasseur, Jean-Louis Le Roux, 6-Sep-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. "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", Tomonori Takeda, Jean-Louis Le Roux, Adrian Farrel, Eiji Oki, 24-Jul-08, A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). "Policy-Enabled Path Computation Framework", Igor Bryskin, Dimitri Papadimitriou, Lou Berger, Gerald Ash, 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 (PCEP)", Nabil Bitar, Kenji Kumaki, Raymond Zhang, 7-May-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 constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol(PCEP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, and between PCEs. The PCEP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCEP are set out in "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCEP in support of inter-AS MPLS TE.Conventions Used in This Document "A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths", JP Vasseur, Raymond Zhang, Nabil Bitar, Jean-Louis Roux, 14-Apr-08, The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems) has been identified as a key requirement. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter- domain shortest constrained paths across a predetermined sequence of domains, using a backward recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. "Definitions of Textual Conventions for Path Computation Element", Emile Stephan, 1-Jul-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines Textual Conventions to represent commonly used Path Computation Element (PCE) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PCE related MIB modules to avoid duplicating conventions. "Inclusion of Manageability Sections in PCE Working Group Drafts", Adrian Farrel, 20-Jun-08, It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the recommendation for all new Internet-Drafts in the PCE Working Group to include a "Manageability Considerations" section, and gives guidance on what that section should contain. "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", Tomonori Takeda, Eiji Oki, Adrian Farrel, 18-Jul-08, The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed route exclusions. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", Richard Bradford, JP Vasseur, 12-May-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, 14-Jul-08, The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. In this context a PCC may be a Label Switching Router (LSR), a Network Management System (NMS), or another PCE. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all LSPs. A GCO may also be applied to some subset of the LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. While GCO is applicable to any simultaneous request for multiple LSPs (for example, a request for end-to-end protection), it is not invisaged that global concurrent reoptimization would be applied in a network (such as an MPLS-TE network) that contains a very large number of very low bandwidth or zero bandwidth LSPs since the large scope of the problem and the small benefit of concurrent reoptimization relative to single LSP reoptimization is unlikely to make the process worthwhile. Further, applying global concurrent reoptimization in a network with a high rate of change of LSPs (churn) is not advised because of the likelihood that LSPs would change before they could be gloablly reoptimized. Global reoptimization is more applicable to stable networks such as transport networks or those with long-term TE LSP tunnels. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", Jean-Louis Le Roux, JP Vasseur, Young Lee, 6-Sep-08, The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks, is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g. minimum cost path, widest path, etc.). In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions, therefore it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE. This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and so that a PCE can report in a path computation reply the objective function that was used for path computation. "A set of monitoring tools for Path Computation Element based Architecture", JP Vasseur, Jean-Louis Le Roux, Yuichi Ikejiri, 4-Sep-08, A Path Computation Element (PCE) based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems). In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain, detection of potential resource contention states and statistics in term of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. "Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol", Siva Sivabalan, Jon Parker, Sami Boutros, Kenji Kumaki, 23-May-08, This document specifies a CLASSTYPE object to support Diff-Serve Aware Traffic Engineering (DS-TE) where path computation is performed with an aid of Path Computation Element (PCE). "Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", Eiji Oki, Jean-Louis Le Roux, Adrian Farrel, 30-Jun-08, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. "draft-ietf-pce-p2mp-app-00.txt", Seisho Yasukawa, Adrian Farrel, 8-Aug-08, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths, and examines which of the PCE architectural models are appropriate. "PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)", Seisho Yasukawa, Adrian Farrel, 8-Aug-08, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. "draft-ietf-pce-pcep-p2mp-extensions-00.txt", Quintin Zhao, Daniel King, Fabien Verhaeghe, Tomonori Takeda, Mohamad Chaitou, Jean-Louis Le Roux, Zafar Ali, 9-Sep-08, Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes extensions to the PCE Communication Protocol PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. "Requirements for GMPLS applications of PCE", Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, 17-Sep-08, The initial effort of PCE WG is specifically focused on MPLS (Multi- protocol label switching). As a next step, this draft describes functional requirements for GMPLS (Generalized MPLS) application of PCE (Path computation element). "The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations", Itaru Nishioka, Daniel King, 29-Sep-08, A Path Computation Element (PCE) performing dependent path computations, for instance calculating a diverse working and protected path do not share common network points, would need to synchronize the computations in order to increase the probability of meeting the working and protected path disjoint objective and network resource optimization objective. When a PCE computes multiple sets of dependent path computation requests concurrently, it is required to use Synchronization VECtor (SVEC) list for association among the sets of dependent path computation requests. This document describes the usage of multiple SVECs in the SVEC list and its processing guideline, for the synchronized computation of dependent paths. Congestion and Pre-Congestion Notification (pcn) ------------------------------------------------ "Pre-Congestion Notification (PCN) Architecture", Philip Eardley, 30-Sep-08, This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established inelastic flows within a single DiffServ domain.Status "Baseline Encoding and Transport of Pre-Congestion Information", T Moncaster, Bob Briscoe, Michael Menth, 30-Sep-08, Pre-congestion notification (PCN) provides information to support admission control and flow termination in order to protect the Quality of Service of inelastic flows. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This document specifies how such marks are to be encoded into the IP header. The baseline encoding described here provides for only two PCN encoding states. It is designed to be easily extensible to provide more encoding states but such schemes will be described in other documents. "Marking behaviour of PCN-nodes", Philip Eardley, 2-Oct-08, This document standardises the two marking behaviours of PCN-nodes: threshold marking and excess traffic marking. Threshold marking marks all PCN-packets if the PCN traffic rate is greater than a first configured rate. Excess traffic marking marks a proportion of PCN- packets, such that the amount marked equals the traffic rate in excess of a second configured rate. Protocol Independent Multicast (pim) ------------------------------------ "The PIM Join Attribute Format", A Boers, IJsbrand Wijnands, Eric Rosen, 6-Oct-08, A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by a multicast group address and a source address, which is possibly a "wild card". Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there is up to now no way to do so. This document describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format. "Authentication and Confidentiality in PIM-SM Link-local Messages", John Atwood, Salekul Islam, Maziar Siami, 28-Aug-08, RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link local messages using the IP security (IPsec) Authentication Header (AH) or Encapsulating Security Payload (ESP). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, an optional automated group key management mechanism is specified. "Population Count Extensions to PIM", Dino Farinacci, Greg Shepherd, 28-Jul-08, This specification defines a method for providing multicast distribution-tree accounting data for billing and debugging. Simple extensions to the PIM protocol allow a rough approximation of tree- based data in a scalable fashion. "A Reliable Transport Mechanism for PIM", Dino Farinacci, IJsbrand Wijnands, Apoorva Karan, A Boers, Maria Napierala, 22-Aug-08, This draft describes how a reliable transport mechanism can be used by the PIM protocol to optimize CPU and bandwidth resource utilization by eliminating periodic Join/Prune message transmission. This draft proposes a modular extension to PIM to use either the TCP or SCTP transport protocol. Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", Quynh Dang, 19-Jun-08, This document supplements RFC 3279. It specifies algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384 or SHA- 512 as hashing algorithm. This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). "Elliptic Curve Cryptography Subject Public Key Information", Sean Turner, Kelvin Yiu, Daniel R. L. Brown, Russ Housley, William Polk, 22-Sep-08, This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5, 3, and 5 of RFC 3279. "New ASN.1 Modules for PKIX", Paul Hoffman, Jim Schaad, 10-Jul-08, The PKIX certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. "Update for RSAES-OAEP Algorithm Parameters", Sean Turner, Kelvin Yiu, Daniel R. L. Brown, Russ Housley, William Polk, 1-May-08, This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. "Traceable Anonymous Certificate", Sanghwan Park, Haeryong Park, Yoojae Won, Jaeil Lee, Stephen Kent, 4-Jun-08, Public Key Infrastructure (PKI) provides a powerful means of authenticating individuals, organizations, and computers (e.g., web servers). However, when individuals use certificates to access resources on the public Internet, there are legitimate concerns about personal privacy, and thus there are increasing demands for privacy enhancing techniques on the Internet. In a PKI, an authorized entity such as a certification Authority (CA) or a Registration Authority (RA) may be perceived, from a privacy perspective, as a "big brother," even when a CA issues a certificate containing a Subject name that is a pseudonym. This is because such entities can always map a pseudonym in a certificate they issued to the name of the real user to whom it was issued. This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request protocols such as PKCS10 [2] CRMF [3]. The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Anonymous Issuer) and the other for validating the contents of a certificate (Blind Issuer). The end-entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). "Trust Anchor Management Requirements", Raksha Reddy, Carl Wallace, 3-Oct-08, A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and protocols designed to address these problems. This document discusses only public keys as trust anchors; symmetric key trust anchors are not considered. "PKI Resource Query Protocol (PRQP)", Massimiliano Pala, 2-Jul-08, One of the most strategic problems still open in PKIX is locating public data and services associated with a Certification Authority (CA). This issue impacts interoperability and usability in PKIX. This draft describes the PKI Resource Query Protocol (PRQP), its design, definition, and its impact in already deployed PKIX protocols. "Other Certificates Extension", Stephen Farrell, 29-Sep-08, Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates belonging to the same end entity that can safely be considered to be equivalent for the purposes of referencing that application state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit. "Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate Extension", Russ Housley, Sam Ashmore, Carl Wallace, 6-Oct-08, This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints X.509 certificate extension. This extension is used to determine whether the public key in an X.509 public key certificate is appropriate to use in the processing of a protected content. In particular, the CMS content constraints certificate extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this certificate extension indicates the content types that the certified public key is authorized to validate. If the authorization check is successful, the CMS content constraints certificate extension also provides default values for absent attributes. "Trust Anchor Format", Russ Housley, Sam Ashmore, Carl Wallace, 6-Oct-08, This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in Trust Anchor Management Requirements and for use within the context of the Trust Anchor Management Protocol (TAMP). "Trust Anchor Management Protocol (TAMP)", Russ Housley, Sam Ashmore, Carl Wallace, 6-Oct-08, This document describes a transport independent protocol for the management of trust anchors and community identifiers stored in a trust anchor store. The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate or TrustAnchorInfo objects. Performance Metrics for Other Layers (pmol) ------------------------------------------- "SIP End-to-End Performance Metrics", Daryl Malas, 25-Jun-08, This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) based services in both production and testing environments. The purpose of this document is to combine a set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. "Framework for Performance Metric Development", Alan Clark, 4-Jul-08, This memo describes a framework and guidelines for the development of performance metrics that are beyond the scope of existing working group charters in the IETF. In this version, the memo refers to a Performance Metrics Entity, or PM Entity, which may in future be a working group or directorate or a combination of these two. Packet Sampling (psamp) ----------------------- "A Framework for Packet Selection and Reporting", Derek Chiou, Benoit Claise, Nick Duffield, Albert Greenberg, Matthias Grossglauser, Jennifer Rexford, Sharon Goldberg, 26-Jun-08, This document specifies a framework for the PSAMP (Packet SAMPling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized selectors, to form a stream of reports on the selected packets, and to export the reports to a collector. This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting and exporting are described, along with configuration requirements of the PSAMP functions. "Sampling and Filtering Techniques for IP Packet Selection", Tanja Zseby, 10-Jul-08, This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. "Packet Sampling (PSAMP) Protocol Specifications", Benoit Claise, 18-Dec-07, This document specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collecting Process. For export of packet information the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. "Information Model for Packet Sampling Exports", Thomas Dietz, Benoit Claise, Paul Aitken, Falko Dressler, Georg Carle, 11-Sep-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, 29-Apr-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, 29-Apr-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudo wire encapsulation for structured or unstructured TDM (T1, E1, T3, E3) circuits over a Packet Switch Network (PSN). "Pseudo Wire (PW) OAM Message Mapping", Thomas Nadeau, Monique Morrow, Luca Martini, Carlos Pignataro, Dinesh Mohan, 28-Jul-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 such that a homogenous PW service can be constructed. "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", Matthew Bocci, Luca Martini, 9-Jun-08, 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, differentautonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains. "Segmented Pseudo Wire", Thomas Nadeau, Chris Metz, Michael Duckett, Matthew Bocci, Florin Balus, Luca Martini, 25-Jul-08, This document describes how to connect pseudowires (PW) between two distinct PW control planes or PSN domains. The PW control planes may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. "Dynamic Placement of Multi Segment Pseudo Wires", Luca Martini, Matthew Bocci, Nabil Bitar, Himanshu Shah, Mustapha Aissaoui, Florin Balus, 25-Jul-08, There is a requirement for service providers to be able to extend the reach of pseudo wires (PW) across multiple Packet Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudo wire among a set of Provider Edge (PE) routers. "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", Matthew Bocci, Stewart Bryant, 25-Sep-08, This document describes an architecture for extending pseudowire emulation across multiple packet switched network segments. Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, and where the emulated service originates and terminates on the same providers PSN, but may pass through several PSN tunnel segments in that PSN. It presents an architectural framework for such multi-segment pseudowires, defines "Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks", Moran Roth, Tel Aviv, David Zelig, Tel Aviv, San Jose, 19-Aug-08, A Fibre Channel pseudowire (PW) is used to carry Fibre Channel frames over an MPLS network. This enables service providers to offer "emulated" Fibre Channel services over existing MPLS networks. This document specifies the encapsulation of Fibre Channel PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a Fibre Channel service. "Pseudowire Congestion Control Framework", Stewart Bryant, Bruce Davie, Luca Martini, Eric Rosen, 28-May-08, Pseudowires are sometimes used to carry non-TCP data flows. In these circumstances the service payload will not react to network congestion by reducing its offered load. Pseudowires should therefore reduces their network bandwidth demands in the face of significant packet loss, including if necessary completely ceasing transmission. Since it is difficult to determine a priori the number of equivalent TCP flow that a pseudowire represents, a suitably "fair" rate of back-off cannot be pre-determined. This document describes pseudowire congestion problem and provides guidance on the development suitable solutions. "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Thomas Nadeau, Carlos Pignataro, 25-Jun-08, This document describes new Connectivity Verification (CV) types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a Pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. "Preferential Forwarding Status bit definition", Praveen Muley, Matthew Bocci, Luca Martini, 30-Sep-08, This document describes a mechanism for standby status signaling of redundant PWs between their termination points. A set of redundant PWs is configured between PE nodes in SS-PW applications, or between T-PE nodes in MS-PW applications. In order for the PE/T-PE nodes to indicate the preferred PW path to forward to one another, a new status bit is needed to indicate a preferential forwarding status of active or standby for each PW in the redundancy set. In addition, a second status bit is defined to allow peer PE/T-PE nodes to coordinate a switchover operation of the PW/MS-PW path. "Pseudowire (PW) Redundancy", Praveen Muley, Matthew Bocci, 30-Sep-08, This document describes a framework comprised of few scenarios and associated requirements where PW redundancy is needed. A set of redundant PWs is configured between PE nodes in SS-PW applications, or between T-PE nodes in MS-PW applications. In order for the PE/T-PE nodes to indicate the preferred PW path to forward to one another, a new status is needed to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. "Requirements for Point-to-Multipoint Pseudowire", Frederic JOUNAY, Philippe Niger, Yuji Kamite, Simon DeLord, Luca Martini, 4-Sep-08, This document presents a set of requirements for providing an unidirectional Point-to-Multipoint PWE3 (Pseudowire Emulation Edge to Edge) emulation. The requirements identified in this document are related to architecture, signaling and maintenance aspects of a Point-to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications Point-to-Multipoint PWs SHOULD be used to optimize the support of multicast services as defined in the Layer 2 Virtual Private Network working group. RADIUS EXTensions (radext) -------------------------- "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", David Nelson, Greg Weber, 10-Oct-08, This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via framed management protocols, and for management access over a secure transport protocol. "RADIUS Design Guidelines", Greg Weber, Alan DeKok, Intellectual Property, 26-Aug-08, This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). "Extended Remote Authentication Dial In User Service (RADIUS) Attributes", Yong Li, Avi Lior, Glen Zorn, 7-Jul-08, For the Remote Authentication Dial In User Service (RADIUS) protocol to continue to support new applications the RADIUS attribute type space must be extended beyond the current limit of 255 possible attribute types while maintaining backwards compatibility with the existing protocol. This document defines a mechanism to accomplish that task, along with standard methods to group together related attributes and to encode values that don't fit into 253 octets. "Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)", David Nelson, 8-May-08, This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). "TLS encryption for RADIUS over TCP (RadSec)", Stefan Winter, Mike McCauley, Stig Venaas, Klaas Wierenga, 22-Aug-08, This document specifies security on the transport layer (TLS) for the RADIUS protocol [RFC2865] when transmitted over TCP [I-D.dekok-radext-tcp-transport]. This enables dynamic trust relationships between RADIUS servers. "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", Alan DeKok, 25-Aug-08, RFC 2865 defines a Status-Server code for use in RADIUS, but labels it as "Experimental" without further discussion. This document describes a practical use for the Status-Server packet code, which is to let clients query the status of a RADIUS server. These queries, and responses (if any) enable the client to make more informed decisions. The result is a more stable, and more robust RADIUS architecture. Reliable Multicast Transport (rmt) ---------------------------------- "Layered Coding Transport (LCT) Building Block", Michael Luby, Mark Watson, Lorenzo Vicisano, 12-Jul-08, Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This document obsoletes RFC3451 "Basic Forward Error Correction (FEC) Schemes", Mark Watson, 14-Jul-08, 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. This document obsoletes RFC3695 and assumes responsibility for the FEC Schemes defined in RFC3452. "FLUTE - File Delivery over Unidirectional Transport", Michael Luby, Rami Lehtonen, Vincent Roca, Toni Paila, 25-Sep-08, This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. "Multicast Negative-Acknowledgment (NACK) Building Blocks", Brian Adamson, Carsten Bormann, University London, Joseph Macker, 9-Sep-08, This document discusses the creation of reliable multicast protocols utilizing negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941. "Reed-Solomon Forward Error Correction (FEC) Schemes", Jerome Lacan, Vincent Roca, Jani Peltotalo, Sami Peltotalo, 12-Nov-07, This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), with m in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-Specified FEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8). Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo. "Security and Reliable Multicast Transport Protocols: Discussions and Guidelines", Brian Adamson, Vincent Roca, 14-Jul-08, This document describes general security considerations for the Reliable Multicast Transport (RMT) Working Group set of building blocks and protocols. An emphasis is placed on risks that might be resolved in the scope of transport protocol design. However, relevant security issues related to IP Multicast control-plane and other concerns not strictly within the scope of reliable transport protocol design are also discussed. The document also begins an exploration of approaches that could be embraced to mitigate these risks. The purpose of this document is to provide a consolidated security discussion and provide a basis for further 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, Rohan Jassani, Chris Christou, Jonah Pezeshki, Carsten Bormann, 14-Aug-08, IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (RoHC) over IPsec (RoHCoIPsec). By compressing the inner headers of IP packets, RoHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs). "IKEv2 Extensions to Support Robust Header Compression over IPsec (RoHCoIPsec)", Jonah Pezeshki, Emre Ertekin, Rohan Jassani, Chris Christou, 14-Aug-08, In order to integrate RoHC with IPsec [ROHCOIPSEC], a mechanism is needed to negotiate RoHC configuration parameters between end-points. Internet Key Exchange (IKE) is a mechanism which can be leveraged to handle these negotiations. This document specifies extensions to IKEv2 [IKEV2] that will allow RoHC and its associated configuration parameters to be negotiated for IPsec security associations (SAs). "IPsec Extensions to Support Robust Header Compression over IPsec (RoHCoIPsec)", Emre Ertekin, Jonah Pezeshki, Michele Casey, Chris Christou, Carsten Bormann, 14-Aug-08, Integrating RoHC with IPsec (RoHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, extensions to the SPD and SAD are required in order to integrate RoHC with IPsec. This document describes the IPsec extensions required to support RoHCoIPsec. "The RObust Header Compression (ROHC) Framework", Kristofer Sandlund, Ghyslain Pelletier, Lars-Erik Jonsson, 4-Aug-08, The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics. The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. Routing Over Low power and Lossy networks (roll) ------------------------------------------------ "Urban WSNs Routing Requirements in Low Power and Lossy Networks", Mischa Dohler, Thomas Watteyne, Tim Winter, Christian Jacquenet, Giyyarpuram Madhusudan, Gabriel Chegaray, Dominique Barthel, 3-Jul-08, The application-specific routing requirements for Urban Low Power and Lossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve the people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data, such as required in smart metering, waste disposal, meteorological, pollution and allergy reporting applications. The majority of these nodes is expected to communicate wirelessly which - given the limited radio range and the large number of nodes - requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoors urban application scenarios. As such, for a wireless ROLL solution to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of requirements reflecting these and further U-LLNs tailored characteristics. "Industrial Routing Requirements in Low Power and Lossy Networks", Dust Networks, Pascal Thubert, Sicco Dwars, Tom Phinney, 8-Jul-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. "Home Automation Routing Requirement in Low Power and Lossy Networks", Anders Brandt, Jakob Buron, Giorgio Porcu, 11-Sep-08, This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers. Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home control and automation environment. "Overview of Existing Routing Protocols for Low Power and Lossy Networks", Arsalan Tavakoli, Stephen Dawson-Haggerty, P Levis, 26-Sep-08, Networks of low power wireless devices introduce novel IP routing issues. Low-power wireless devices, such as sensors, actuators and smart objects, have difficult constraints: very limited memory, little processing power, and long sleep periods. As most of these devices are battery-powered, energy efficiency is critically important. Wireless link qualities can vary significantly over time, requiring protocols to make agile decisions yet minimize topology change energy costs. Routing over such low power and lossy networks has novel requirements that existing protocols may not address. This document provides a brief survey of the strengths and weaknesses of existing protocols with respect to this class of networks. From this survey it examines whether existing protocols as described in RFCs and mature drafts could be used without modification in these networks, or whether further work is necessary. Routing Protocol Security Requirements (rpsec) ---------------------------------------------- "BGP Session Security Requirements", Michael Behringer, 10-Jul-08, The document "BGP security requirements" (draft-ietf-rpsec-bgpsecrec) specifies general security requirements for BGP. However, specific security requirements for single BGP sessions, i.e., the connection between two BGP peers, are only touched on briefly in the section "transport layer protection". This document expands on this particular aspect of BGP security, defining the security requirements between two BGP peers. Reliable Server Pooling (rserpool) ---------------------------------- "Reliable Server Pooling: Management Information Base using SMIv2", Thomas Dreibholz, Jaiwant Mulik, 9-Oct-08, RSerPool [RFC5351] is a framework to provide reliable server pooling. This document defines a SMIv2 compliant Management Information Base (MIB) providing access to managed objects in an RSerPool implementation. Simple Authentication and Security Layer (sasl) ----------------------------------------------- "The CRAM-MD5 SASL Mechanism", Lyndon Nerenberg, 11-Jul-08, This document defines a simple challenge-response authentication mechanism, using a keyed MD5 digest, for use with the Simple Authentication and Security Layer (SASL). "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", Simon Josefsson, 13-Jul-08, This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous SASL/GSS-API mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports a SASL-specific notion of channel binding. See for more information. "Moving DIGEST-MD5 to Historic", Alexey Melnikov, 29-Jul-08, This memo describes problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism as specified in RFC 2831. It recommends that DIGEST-MD5 to be marked as OBSOLETE in the IANA Registry of SASL mechanisms, and that RFC 2831 be moved to Historic status. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to ietf-sasl@imc.org. "Simple Authentication and Security Layer (SASL)", Alexey Melnikov, Kurt Zeilenga, 31-Aug-08, The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism. This document obsoletes RFC 4422 [[when approved]]. Site Multihoming by IPv6 Intermediation (shim6) ----------------------------------------------- "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Jari Arkko, Iljitsch van Beijnum, 24-Jun-08, This document specifies how the level 3 multihoming shim protocol (SHIM6) detects failures between two communicating hosts. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same hosts if a failure occurs and an operational pair can be found. "Hash Based Addresses (HBA)", Marcelo Bagnulo, 22-Dec-07, This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. This mechanism employs either Cryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash Based Addresses (HBAs), that are inherently bound to each other. "Shim6: Level 3 Multihoming Shim Protocol for IPv6", Erik Nordmark, Marcelo Bagnulo, 14-Feb-08, This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load sharing properties, without assuming that a multihomed site will have a provider independent IPv6 address prefix which is announced in the global IPv6 routing table. The hosts in a site which has multiple provider allocated IPv6 address prefixes, will use the Shim6 protocol specified in this document to setup state with peer hosts, so that the state can later be used to failover to a different locator pair, should the original one stop working. "Socket Application Program Interface (API) for Multihoming Shim", Miika Komu, Marcelo Bagnulo, Kristian Slavov, Shinta Sugimoto, 26-Aug-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, 18-Sep-08, This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-of-use" of an Internet Number Resource (IP Addresses and Autonomous System Numbers). This profile is used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of- use" of the IP addresses and AS numbers that are described in the issued certificate. "A Profile for Route Origin Authorizations (ROAs)", Stephen Kent, 7-Jul-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. "A Protocol for Provisioning Resource Certificates", Geoff Huston, Robert Loomans, Byron Ellacott, Rob Austein, 6-Aug-08, This document defines a framework for certificate management interactions between a resource issuer ("Internet Registry" or "IR") and a resource recipient ("Internet Service Provider" or "ISP") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the ISP, and corresponding responses from the IR encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework. "Manifests for the Resource Public Key Infrastructure", Rob Austein, Geoff Huston, Stephen Kent, Matt Lepinski, 23-Sep-08, This document defines a "manifest" for use in the Resource Public Key Infrastructure. A manifest is a signed object that contains a listing of all the signed objects in the repository publication point associated with an authority responsible for publishing in the repository. For each certificate, or other forms of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to expose potential attacks against relying parties of the Resource Public Key Infrastructure, such as a man-in-the middle attack of withholding repository data from relying party access, or replaying stale repository data to a relying party's access request. "Validation of Route Origination in BGP using the Resource Certificate PKI", Geoff Huston, George Michaelson, 5-Oct-08, This document defines an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. The proposed application is intended to fit within the requirements for adding security to inter-domain routing, including the ability to support incremental and piecemeal deployment, and does not require any changes to the specification of BGP. "A Profile for Bogon Origin Attestations (BOAs)", Geoff Huston, George Michaelson, Terry Manderson, 5-Oct-08, This document defines a standard profile for Bogon Origin Attestations (BOAs). A BOA is a digitally signed object that provides a means of verifying that an IP address block holder has not authorized any Autonomous System (AS) to originate routes that are equivalent to any of the addresses listed in the BOA. A BOA also provides a means of verifying that BGP speaker is not using an AS without appropriate authority to use that AS. The proposed application of BOAs is intended to fit within the requirements for adding security measures to inter-domain routing, including the ability to support incremental and piecemeal deployment of such measures, and does not require any changes to the specification of the Border Gateway Protocol. "A Profile for Resource Certificate Repository Structure", Geoff Huston, Robert Loomans, George Michaelson, 4-Oct-08, This document defines a profile for the structure of repository publication points that contain X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile contains the proposed object naming scheme, the contents of repository publication points, the contents of publication point manifests and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and facilitate certification path construction. Sieve Mail Filtering Language (sieve) ------------------------------------- "Sieve Email Filtering: Reject and Extended Reject Extensions", Aaron Stone, Matthew Elvey, Alexey Melnikov, 27-May-08, This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028. A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs. This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the "ereject" action to require messages to be refused during the SMTP transaction, if possible. The "ereject" action is intended to replace the "reject" action wherever possible. "SIEVE Email Filtering: Extension for Notifications", Alexey Melnikov, Barry Leiba, Wolfgang Segmuller, Tim Martin, 24-Dec-07, Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method but it is expected that using existing instant messaging infrastructure such as XMPP, or GSM Short Message Service (SMS) messages will be popular. This draft describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. "Sieve Notification Mechanism: mailto", Barry Leiba, Michael Haardt, 1-Oct-08, This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. "Sieve Notification Mechanism: xmpp", Peter Saint-Andre, Alexey Melnikov, 19-Feb-08, This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber. "Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure", Tony Hansen, Cyrus Daboo, 12-Sep-08, This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. Note This document is being discussed on the MTA-FILTERS mailing list, ietf-mta-filters@imc.org. "Sieve Email Filtering: Ihave Extension", Ned Freed, 9-Oct-08, This document describes the "ihave" extension to the Sieve email filtering language. The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script. "Sieve Email Filtering: Notary Extension", Ned Freed, 31-Jul-08, This document describes the "dsn-envelope" and "dsn-redirect" extensions to the Sieve email filtering language. The "dsn-envelope" extension provides access to additional envelope information provided by the delivery status notification extension to SMTP defined in RFC 3461. The "dsn-redirect" extension extends Sieve's redirect action to provide control over delivery status notification parameters. SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- "An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources", Jonathan Rosenberg, Jari Urpalainen, 5-May-08, This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format indicates the document that has changed and its former and new entity tags. It also can indicate the specific change that was made in the document, using an XML patch format. This format allows also indications of element and attribute content of an XML document. XCAP diff documents can be delivered to clients using a number of means, including a Session Initiation Protocol (SIP) event package. "Instant Message Disposition Notification", Eric Burger, Hisham Khartabil, 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. "SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 9-Jul-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, 14-Jul-08, Presence federation refers to the exchange of presence information between systems. One of the primary challenges in presence federation is scale. With a large number of watchers in one domain obtaining presence for many presentities in another, the amount of notification traffic is large. This document describes an extension to the Session Initiation Protocol (SIP) event framework, called view sharing. View sharing can substantially reduce the amount of traffic, but requires a certain level of trust between domains. View sharing allows the amount of presence traffic between domains to achieve the theoretical lower bound on information exchange in any presence system. "Models for Intra-Domain Presence and Instant Messaging (IM) Federation", Jonathan Rosenberg, Avshalom Houri, Colm Smyth, 14-Jul-08, Presence and Instant Messaging (IM) federation involves the sharing of presence information and exchange of IM across multiple systems. Most often, presence and IM 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 presence and IM federation. Session Initiation Protocol (sip) --------------------------------- "Connection Reuse in the Session Initiation Protocol (SIP)", Rohan Mahy, Vijay Gurbani, Brett Tate, 14-Jul-08, This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forward and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through TLS. For this reason, we only consider connection reuse for TLS over TCP and TLS over SCTP. A single connection should not 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, 29-Sep-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, 16-Jun-08, The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its Registrar. "Requesting Answering Modes for the Session Initiation Protocol (SIP)", Dean Willis, Andrew Allen, 28-May-08, This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or instead accepts the request without waiting on user input. The second header, "Priv- Answer-Mode" is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as Push-to-Talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", Robert Sparks, Scott Lawrence, Alan Hawrylyshen, Byron Campen, 3-Jul-08, This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. "Certificate Management Service for The Session Initiation Protocol (SIP)", Cullen Jennings, Jason Fischl, 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, 14-Jul-08, This document specifies a Session Initiation Protocol (SIP) profile of Security Assertion Markup Language (SAML) as well as a SAML SIP binding. The defined SIP SAML Profile composes with the mechanisms defined in the SIP Identity specification and satisfy requirements presented in "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)". "A Hitchhiker's Guide to the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 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. "A Framework for Session Initiation Protocol (SIP) Session Policies", Volker Hilt, Gonzalo Camarillo, Jonathan Rosenberg, 22-Aug-08, Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. "The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", Francois Audet, 23-Feb-08, This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. This document also provides a discussion of possible future steps in specification. "Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 19-Jun-07, This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a UA to communicate to its registrar that it supports ICE. The option tag allows a User Agent (UA) to require support for ICE in order for a call to proceed. "An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification", Aki Niemi, 14-Jul-08, The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures have a serious deficiency in that they provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. "Addressing Record-Route issues in the Session Initiation Protocol (SIP)", Thomas Froment, Christophe Lebel, Ben Bonnaerens, 6-Oct-08, A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) indicating where and how the subsequent requests should be sent to reach the proxy. Like any SIP URI, it can contain sip or sips schemes, IPv4 or IPv6 addresses, and URI parameters that could influence the routing such as the transport parameter (for example transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching or IPv4 to IPv6 scenarios...), the question arises on what should be put in Record-Route header(s). It is just not possible to make one header having the characteristics of both sides at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC3261 text, which describes only a Record-Route rewriting solution. "Message Body Handling in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 8-Aug-08, This document specifies how message bodies are handled in SIP. Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. "Requirements and Analysis of Media Security Management Protocols", Dan Wing, Steffen Fries, Hannes Tschofenig, Francois Audet, 2-Jun-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, 6-Oct-08, This memo documents an extended key usage (EKU) X.509 certificate extension for identifying the holder of a certificate as authoritative for a Session Initiation Protocol (SIP) service in the domain named by the DNS name in the certificate. "Domain Certificates in the Session Initiation Protocol (SIP)", Vijay Gurbani, Scott Lawrence, Bell Laboratories, 6-Oct-08, This document describes how to interpret certain information in a X.509 PKIX-compliant certificate used in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to find the right identity for authentication in such certificates and how to use that identity for SIP domain authentication. "Framework for Establishing an SRTP Security Context using DTLS", Jason Fischl, Hannes Tschofenig, Eric Rescorla, 1-Oct-08, This document specifies how to use the Session Initiation Protocol (SIP) to establish an Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. "UA-Driven Privacy Mechanism for SIP", Mayumi Munakata, Shida Schubert, Takumi Ohba, 14-Jul-08, This document defines a best current practice for a user agent to generate an anonymous SIP message by utilizing mechanisms such as GRUU and TURN without the need for a privacy service defined in RFC 3323. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package", Jari Urpalainen, 3-Oct-08, This document describes an "xcap-diff" SIP event package for the SIP Event Notification Framework, which clients can use to receive notifications of the partial changes of Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization information exchange and document updates are based on the XCAP-Diff format. "Essential correction for IPv6 ABNF and URI comparison in RFC3261", Vijay Gurbani, Brian Carpenter, Brett Tate, 6-May-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. "Response Code for Indication of Terminated Dialog", Christer Holmberg, 27-Aug-08, This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP entity can use to indicate upstream that an early dialog has been terminated. The response code can be used by a SIP entity to indicate to the UAC that an early dialog has been terminated, before a final response is sent to the UAC. Session Initiation Proposal Investigation (sipping) --------------------------------------------------- "Session Initiation Protocol Service Examples", Alan Johnston, Robert Sparks, Chris Cunningham, Steve Donovan, Kevin Summers, 11-Jul-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, Robert Sparks, Jonathan Rosenberg, Dan Petrie, Alan Johnston, 16-Apr-08, This document defines a framework and requirements for call control and multi-party usage of SIP. To enable discussion of multi-party features and applications we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually setup the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state, and session history. This framework also describes other goals that embody the spirit of SIP applications as used on the Internet. "Best Current Practices for NAT Traversal for Client-Server SIP", Chris Boulton, Jonathan Rosenberg, Gonzalo Camarillo, Francois Audet, 17-Sep-08, Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently there are many deployment scenarios and traversal mechanisms for media traffic. This document aims to provide concrete recommendations and a unified method for NAT traversal as well as documenting corresponding flows. "Session Initiation Protocol Call Control - Transfer", Robert Sparks, Alan Johnston, 3-Sep-08, This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. "A Framework for Session Initiation Protocol User Agent Profile Delivery", Sumanth Channabasappa, 13-Feb-08, This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) User Agents in SIP deployments. The framework provides a means to deliver profile data that User Agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP User Agents can discover sources, request profiles and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope. "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 20-Jul-05, This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual Tone Multi Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. "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. "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, Gonzalo Camarillo, Jonathan Rosenberg, 12-Jul-08, This specification defines a document format for the media properties of Session Initiation Protocol (SIP) sessions. Examples for media properties are the codecs or media types used in a session. This document format is based on XML and extends the Schema for SIP User Agent Profile Data Sets. It can be used to describe the properties of a specific SIP session or to define policies that are then applied to different SIP sessions. "Session Initiation Protocol Package for Voice Quality Reporting Event", Alan Clark, Amy Pendleton, Alan Johnston, Henry Sinnreich, 9-Oct-08, This document defines a SIP event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists", Miguel Garcia, Gonzalo Camarillo, 1-Aug-08, 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, 12-Jul-08, This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents to subscribe to session policies for a SIP session and to receive notifications if these policies change. "The Session Initiation Protocol (SIP) Pending Additions Event Package", Gonzalo Camarillo, 26-May-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, 1-Aug-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, 16-Jun-08, This document describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or additional standards work is required. "Requirements for Management of Overload in the Session Initiation Protocol", Jonathan Rosenberg, 14-Jul-08, Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insuffient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This draft summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. "SIP (Session Initiation Protocol) Usage of the Offer/Answer Model", Takuya Sawada, Paul Kyzivat, 25-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, 29-Sep-08, This document gives examples call flows of race conditions in the Session Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given. "Identification of Communications Services in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 4-Aug-08, This document considers the problem of service identification in the Session Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent. This document discusses the uses of service identification, and outlines several architectural principles behind the process. It identifies perils when service identification is not done properly - including fraud, interoperability failures and stifling of innovation. "Scaling Requirements for Presence in SIP/SIMPLE", Avshalom Houri, Sriram Parameswar, Edwin Aoki, Vishal Singh, Henning Schulzrinne, 3-Jul-08, The document provides a set of requirements for enabling interdomain scaling in presence for SIP/SIMPLE. "Updates to Asserted Identity in the Session Initiation Protocol (SIP)", John Elwell, 23-Sep-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 certain SIP methods such as UPDATE, REGISTER, MESSAGE, PUBLISH and ACK, 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", Martin Dolly, Sumanth Channabasappa, Sam Ganesan, Volker Hilt, 11-Jul-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) ---------------------------- "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 and Supporting Data Structures", Guido Appenzeller, Luther Martin, Mark Schertler, 9-Oct-08, This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology. "Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS)", Luther Martin, Mark Schertler, 4-Aug-08, This document describes the conventions for using the Boneh- Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. "Multiple Signatures in S/MIME", Sean Turner, Jim Schaad, 11-Mar-08, Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per-signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. "Using SHA2 Algorithms with Cryptographic Message Syntax", Sean Turner, 9-Oct-08, his document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", Sean Turner, Blake Ramsdell, 6-Oct-08, This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", Blake Ramsdell, Sean Turner, 6-Oct-08, This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. "New ASN.1 Modules for CMS and S/MIME", Paul Hoffman, Jim Schaad, 10-Jul-08, The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. "Update to Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", Sean Turner, 6-May-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, Elliptic Curve Digital Signature Algorithm (ECDSA) 224-512, and Key Derivation Functions (KDFs) that utilize SHA2 algorithms. "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", Sean Turner, Daniel R. L. Brown, 29-Sep-08, This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A for key agreement, RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for message digest, and RFCs 2104 and 4231 for message authentication code standards. Softwires (softwire) -------------------- "Softwire Hub & Spoke Deployment Framework with L2TPv2", Bill Storer, Carlos Pignataro, Maria Santos, Bruno Stevant, Jean-Francois Tremblay, 10-Jul-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 Mesh Framework", Jianping Wu, Yong Cui, Xing Li, Chris Metz, Eric Rosen, Simon Barber, Pradosh Mohapatra, John Scudder, Intellectual Property, 18-Sep-08, The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single protocol" networks. One kind of single protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "Softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single protocol network of the other protocol. The document is careful to specify when this can be done with existing technology, and when it requires the development of new or modified technology. "Advertising an IPv4 NLRI with an IPv6 Next Hop", Francois Le Faucheur, Eric Rosen, 24-Apr-08, MultiProtocol-BGP (MP-BGP) specifies that the set of Network Layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising an IPv4 Network Layer Reachability Information (NLRI) or a VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising an IPv4 NLRI or a VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. "BGP Traffic Engineering Attribute", Don Fedyk, Yakov Rekhter, Hamid Ould-Brahim, 10-Sep-08, This document defines a new BGP attribute, Traffic Engineering attribute, than enables BGP to carry Traffic Engineering information. The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. "BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute", Pradosh Mohapatra, Eric Rosen, Intellectual Property, 4-Jun-08, In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another, the BGP next hop, requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header. The encapsulation information need not be signaled for all encapsulation types. In the cases where the signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3), Generic Routing Encapsulation (GRE) with key), this draft specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the "Encapsulation Subsequent Address Family Identifier (SAFI)" and IPv4 or IPv6 Address Family Identifier (AFI). In the cases where no encapsulation information needs to be signaled (such as GRE without key), this draft specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes to indicate the encapsulation protocol type to be used. "BGP IPSec Tunnel Encapsulation Attribute", Lou Berger, Russ White, Eric Rosen, 1-May-08, The BGP Encapsulation Subsequence Address Family Identifiers (SAFI) provides a method for the dynamic exchange of encapsulation information, and the indication of encapsulation protocol types to be used for different next hops. Currently support for GRE and L2TPv3 tunnel types are defined. This document defines support for IPsec tunnel types. Speech Services Control (speechsc) ---------------------------------- "Media Resource Control Protocol Version 2 (MRCPv2)", Saravanan Shanmugham, Daniel Burnett, 20-Jun-08, The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. Session PEERing for Multimedia INTerconnect (speermint) ------------------------------------------------------- "SPEERMINT Terminology", Daryl Malas, Dave Meyer, 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 Session Peering", Jean-Francois Mule, 14-Jul-08, This memo captures protocol requirements to enable session peering of voice, presence, instant messaging and other types of multimedia traffic. It is based on the use cases that have been described in the speermint working group. This informational document is intended to link the session peering use cases to protocol solutions. "SPEERMINT Peering Architecture", Reinaldo Penno, 2-May-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. "SPEERMINT Routing Architecture Message Flows", Hadriel Kaplan, Daryl Malas, Sohel Khan, Reinaldo Penno, Adam Uzelac, 14-Jul-08, This document describes example message flows associated with the SPEERMINT routing architecture, relative to various peering scenarios. "Presence & Instant Messaging Peering Use Cases", Avshalom Houri, 3-Jul-08, he 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, 26-Aug-08, This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) Peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. In describing use cases, the intent is descriptive, not prescriptive. Security Issues in Network Event Logging (syslog) ------------------------------------------------- "Signed syslog Messages", John Kelsey, 4-Oct-07, This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC xxxx, "The syslog Protocol". "The syslog Protocol", Rainer Gerhards, 6-Sep-07, This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the original design goals for traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a standards- track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. This document obsoletes RFC3164. "Transmission of syslog messages over UDP", Anton Okmianski, 5-Sep-07, This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. "TLS Transport Mapping for Syslog", Miao Fuyou, Ma Yuzhi, Joseph Salowey, 1-Oct-08, This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats. "Textual Conventions for Syslog Management", Glenn Mansfield, 22-May-08, This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- "Improving TCP's Robustness to Blind In-Window Attacks", Anantha Ramaiah, Randall Stewart, Mitesh Dalal, 9-Jul-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, 13-Jun-08, The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option - the TCP User Timeout Option - that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", Sally Floyd, Aleksandar Kuzmanovic, Amit Mondal, K. K. Ramakrishnan, 22-Aug-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 updates RFC 3168. "TCP Congestion Control", Mark Allman, 30-Apr-08, This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. "TCP's Reaction to Soft Errors", Fernando Gont, 23-Apr-08, This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages, that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP", Pasi Sarolahti, Markku Kojo, Kazunori Yamamoto, Max Hata, Intellectual Property, 9-Sep-08, 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, 14-Jul-08, 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. "Early Retransmit for TCP and SCTP", Mark Allman, Konstantin Avrachenkov, Urtzi Ayesta, Ethan Blanton, Per Hurtig, 28-Aug-08, This document proposes a new mechanism for TCP and SCTP that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover packet losses that would otherwise require a lengthy retransmission timeout. Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- "Architecture for the Transmission of Timing over Packet Networks", Yaakov Stein, Stewart Bryant, 14-Jul-08, This Internet draft proposes an architecture for the transmission of timing over packet networks. It identifies the major functional components, and maps the current solutions onto this framework. Transport Layer Security (tls) ------------------------------ "Transport Layer Security (TLS) Extensions: Extension Definitions", Donald Eastlake 3rd, 5-Oct-08, This document provides documentation for existing specific TLS extensions. It is a companion document for the TLS 1.2 specification [RFC5246]. The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. "Keying Material Extractors for Transport Layer Security (TLS)", Eric Rescorla, 11-Sep-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, 29-Sep-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, 25-Jun-08, TLS specification versions 1.0 (RFC 2246) and 1.1 (RFC 4346) included cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES (when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS 1.2 main specification (RFC 5246). This document specifies these cipher suites for completeness, and discusses reasons why their use is no longer recommended. "Pre-Shared Key Cipher Suites for Transport Layer Security (TLS) with SHA-256/384 and AES Galois Counter Mode", Mohamad Badra, 25-Sep-08, RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm. This document describes a set of pre-shared key cipher suites for TLS which uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set which uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). "Datagram Transport Layer Security version 1.2", Eric Rescorla, Nagendra Modadugu, 1-Jun-08, This document specifies Version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- "Rbridges: Base Protocol Specification", Radia Perlman, 1-Oct-08, RBridges provide optimal pair-wise forwarding with zero configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count. RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol. The design supports VLANs and optimization of the distribution of multi-destination frames based on VLAN and IP derived multicast groups. It also allows forwarding tables to be 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, 29-Sep-08, Current Ethernet (802.1) link layers use spanning tree protocols that have a number of challenges. These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths (in the case of spanning trees). This document addresses these concerns and suggests that they can be addressed by applying modern network layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing bridged (802.1) links, but that a solution would be backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities. Transport Area Working Group (tsvwg) ------------------------------------ "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Randall Stewart, Kacheong Poon, Michael Tuexen, Vladislav Yasevich, Peter Lei, 14-Jul-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, 13-May-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. "RSVP Extensions for Path-Triggered RSVP Receiver Proxy", Francois Le Faucheur, Jukka Manner, Ashok Narayanan, Allan Guillou, Le Faucheur, 1-Jul-08, RSVP signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the QoS required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to-end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document presenting RSVP Proxy approaches, RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions. "RSVP Proxy Approaches", Francois Le Faucheur, Jukka Manner, Dan Wing, Allan Guillou, 11-Apr-08, The Resource ReSerVation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP- capable. This document presents RSVP Proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP Proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP Proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP Proxy are described. "Unicast UDP Usage Guidelines for Application Designers", Lars Eggert, Gorry Fairhurst, 11-Oct-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 unicast 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, 31-Aug-08, Recently, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput-reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five- tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the random selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods, the described port number randomization algorithms provide improved security/obfuscation with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed, and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, SCTP, DCCP, and RTP. "Applicability of Keying Methods for RSVP Security", Michael Behringer, Francois Le Faucheur, 11-Jul-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. For example, 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. "Support for RSVP in Layer 3 VPNs", Bruce Davie, Francois Le Faucheur, Ashok Narayanan, 3-Jul-08, RFC 4364 and RFC 4659 define an approach to building provider- provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to use RSVP to perform admission control on the links between CE and PE routers. This document specifies procedures by which RSVP messages travelling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported. "IANA Procedures for the Transport Protocol Port Number Space", Michelle Cotton, Lars Eggert, Allison Mankin, Magnus Westerlund, Joseph Touch, 7-Jul-08, This document defines the IANA procedures for registering port number values for use with the various IETF transport protocols, including TCP, UDP, DCCP, and SCTP. It provides clear procedures for the management of the port number registry, which is important for its long-term management. It updates RFC2780 by obsoleting Sections 8 and 9.1 of that RFC, and it updates the IANA allocation procedures for DCCP as defined in RFC4340. "Byte and Packet Congestion Notification", Bob Briscoe, 7-Aug-08, This memo concerns dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre- congestion notification (PCN). The primary conclusion is that packet size should be taken into account when transports read congestion indications, not when network equipment writes them. Reducing drop of small packets has some tempting advantages: i) it drops less control packets, which tend to be small and ii) it makes TCP's bit- rate less dependent on packet size. However, there are ways of addressing these issues at the transport layer, rather than reverse engineering network forwarding to fix specific transport problems. Network layer algorithms like the byte-mode packet drop variant of RED should not be used to drop fewer small packets, because that creates a perverse incentive for transports to use tiny segments, consequently also opening up a DoS vulnerability. Usenet Article Standard Update (usefor) --------------------------------------- "Netnews Article Format", Charles Lindsey, 9-Jan-07, This document specifies the syntax of Netnews articles in the context of the "Internet Message Format" (RFC 2822) and "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. "Netnews Architecture and Protocols", Russ Allbery, Charles Lindsey, 27-Aug-08, This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software which originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles.Internet Draft Comments Comments are solicited and should be addressed to the Usenet Format Working Group at ietf-usefor@imc.org. IPv6 Operations (v6ops) ----------------------- "IPv6 Unicast Address Assignment Considerations", Gunter Van de Velde, Chip Popoviciu, Tim Chown, Olaf Bonness, Christian Hahn, 22-Sep-08, One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network. "Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service", James Woodyatt, 29-Jul-08, This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. "IPv4/IPv6 Coexistence and Transition: Requirements for solutions", Marcelo Bagnulo, Fred Baker, Iljitsch van Beijnum, 13-May-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. "IPv6 RA-Guard", Eric Levy-Abegnoli, Gunter Van de Velde, Chip Popoviciu, Janos Mohacsi, 10-Sep-08, It is particularly easy to experience "rogue" routers on an unsecured link. Devices acting as a rougue router may send illegitimate RAs. Section 6 of SeND [RFC3971] provides a full solution to this problem, by enabling routers certification. This solution does, however, require all nodes on an L2 network segment to support SeND, as well as it carries some deployment challenges. End-nodes must be provisioned with certificate anchors. The solution works better when end-nodes have access to a Certificate Revocation List server, and to a Network Time Protocol server, both typically off-link, which brings some bootstrap issues. When using IPv6 within a single L2 network segment it is possible and sometimes desirable to enable layer 2 devices to drop rogue RAs before they reach end-nodes. In order to distinguish valid from rogue RAs, the L2 devices can use a spectrum of criterias, from a static scheme that blocks RAs received on un-trusted ports, or from un-trusted sources, to a more dynamic scheme that uses SeND to challenge RA sources. This document reviews various techniques applicable on the L2 devices to reduce the threat of rogue RAs. "Security Concerns With Tunneling", James Hoagland, Suresh Krishnan, Dave Thaler, 7-Jul-08, A number of security concerns with tunnels are documented. The primary intent of this document is to raise the awareness regarding the security issues with tunnels as deployed today. vCard and CardDAV (vcarddav) ---------------------------- "vCard Format Specification", Simon Perreault, Pete Resnick, 14-Jul-08, This document defines the vCard data format for representing and exchanging a variety of information about an individual (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). "vCard Extensions to WebDAV (CardDAV)", Cyrus Daboo, 12-Jul-08, This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. Discussion of this Internet-Draft is taking place on the mailing list . "Extended MKCOL for WebDAV", Cyrus Daboo, 14-May-08, This specification extends the WebDAV MKCOL method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. Virtual Router Redundancy Protocol (vrrp) ----------------------------------------- "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, 15-Apr-08, This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and on draft-ieft-vrrp-ipv6-spec-08.txt. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switch over to back up routers than can be obtained with standard IPv6 Neighbor Discover (RFC 4861) mechanisms. WWW Distributed Authoring and Versioning (webdav) ------------------------------------------------- "Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)", Geoffrey Clemm, Jason Crawford, Julian Reschke, Jim Whitehead, 3-Oct-08, This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created.Editorial Note (To be removed by RFC Editor before publication) Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with subject "subscribe" to . Discussions of the WEBDAV working group are archived at . lists all registered issues since draft 02. Centralized Conferencing (xcon) ------------------------------- "Conference Information Data Model for Centralized Conferencing (XCON)", Oscar Novo, Gonzalo Camarillo, David Morgan, Roni Even, 12-Jun-08, This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", Gonzalo Camarillo, Srivatsa Srinivasan, Roni Even, Jari Urpalainen, 3-Sep-08, This document specifies the notification mechanism for XCON (centralized conferencing). This mechanism reuses the SIP (Session Initiation Protocol) event package for conference state. Additionally, the notification mechanism includes support for the XCON data model and for partial notifications. "Centralized Conferencing Manipulation Protocol", Mary Barnes, Chris Boulton, Simon Romano, Henning Schulzrinne, 16-Jun-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 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).